- 08 Feb, 2021 16 commits
-
-
Nils Goroll authored
To allow dynamic SUB calls, we need to check for recursions at runtime, reflecting the compile time recursion check. We create a bitmask to note each dynamically called SUB by its unique number. To check for recursions, we only need to test if the respective bit for the sub number is already set. We only conduct this check if the track_call argument of vcl_call_method() is true. By setting this argument to the number of SUB references, we enable call tracking only for VCLs with dynamic SUB references (when (struct VCL_conf).nsub is non-zero). VCC already guarantees that static calls are loop free - so loops can only be introduced through dynamic SUB references. Call tracking with a bitmask was suggested by phk
-
Nils Goroll authored
Before the addition of the okmask, we could only selectively turn off optimizations for the built-in housekeeping subs (vcl_init {} / vcl_fini {}), not for any custom subs called from there. The previous commit changed this and turned off optimizations for any custom subs called from there. We pull this tighter again by only turning off optimizations for subs which can _only_ be called from housekeeping. Ref f1c47e48 Ref #3230
-
Nils Goroll authored
Improve safety by asserting that a sub is never called from a context which is not allowed as per its okmask. This is to ensure correctness of our compile- and runtime-checks.
-
Nils Goroll authored
We previously missed to run the static recursion check on SUBs which are only referenced symbolically (and thus might be called dynamically). This changes the error reporting tested in v00021.vtc because the recursion is detected on the recursing subs alone before the call tree from vcl_recv {} is walked.
-
Nils Goroll authored
In follow up commits, we will need a marker for subs which can be reachable via dynamically referenced SUBs. We use "more references than calls" is this marker. When walking the call trees, we add one reference for all subs which are called from a SUB having this marker, thus marking those, too.
-
Nils Goroll authored
The .called attribute was not used. We now increment it only for custom subs which are actually called statically (with "call"), that is, not for the builtin subs. This is to simplify and clarify the use case in the next commits. The increment happens for each VCC walk of the SUBs. We also add the number of symbolic references and calls to (struct vcl_sub) of the VGC to facilitate reviews and debugging.
-
Nils Goroll authored
For follow up commits, we will need to know if a VCL contains any references to the SUB type, that is, if the SUB type was used as a vmod function or method argument.
-
Nils Goroll authored
We change the semantics of the rname and lname attributes of SUB symbols: rname now is the name of the (struct vcl_sub), lname is the cname, the name of the function to be called directly from VGC.
-
Nils Goroll authored
We call those subs impossible which use a combination of variables not being available together from any of the built-in subroutines (aka methods), for example:: sub foo { set req.http.impossible = beresp.reason; } For this example, there is no built-in subroutine for which both req and beresp were available, so it can not possibly be valid in any context. As long as subs were actually called directly or indirectly from a built-in sub, VCC did already detect the problem. For the above example, if `sub vcl_recv { call foo; }` existed, VCC would complain about beresp.reason not being accessible from vcl_recv. Except, when vcc_err_unref was disabled, the example would pass without error, and likewise it will with calls which we are about to add. We now add a check to detect impossible subroutines. It happens in a second walk over the VCL's SUB symbols in order to keep the more precise error messages for calls rooting in one of the built-in subs. This change also changes the order of error reporting slightly and incorporates, indirectly, the vcc_CheckUses() check moved in ed36b638. v00020.vtc now has the "Impossible Subroutine with vcc_err_unref off" check, while the newly added m00053.vtc has been changed to test failure of the impossible sub at compile time rather than at runtime. This change was triggered by feedback from Dridi
-
Nils Goroll authored
Until now, the VCC SUB type represented the literal name of a vcc-generated C function, which was used to expand the VCL "call" action. We now add a struct to describe VCL subs and calculate a bitmask which represents the bilt-in subs which a SUB may be called from (the "okmask"), This is in preparation of the goal to add a VCL_SUB vmod type which will allow VMODs to call into vcl subs. We add to the vcl shared object a struct vcl_sub for each sub, which contains: - a methods bitmask defining which built-in subs this sub may be called from (directly or indirectly) - the name as seen from vcl - a pointer back to the VCL_conf - the function pointer to the vcl_func_f - a unique number About the methods bitmask: It contains the VCL_MET_* bits of of built-in subs (traditionally called methods) which are allowed to call this sub. It is intended for checks like if (sub->methods & ctx->method) { sub->func(ctx); return; } else { VRT_fail(ctx, "not allowed here"); return; } In existing compile-time calls, we already check if used objects and returned actions are allowed within the respective calling context. To build the methods bitmask, we begin with a VCL_MET_TASK_ALL bitfield and clear the bits of methods which would not be allowed for any used object or returned action. About the VCL_conf pointer: Each VCL SUB belongs to a VCL, this pointer will allow to check that it is only ever used from the right VCL. About the unique number: By numbering vcl subs (per VCL), we can later implement a recursion check using a bitmask. In struct VCL_conf, we record the total number of subs.
-
Nils Goroll authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
(If it wasnt because vtcp has spread to other code I would assert that the fd is larger than stderr.)
-
- 04 Feb, 2021 5 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
(VRT_synth_page() still works, but is now deprecated.)
-
Poul-Henning Kamp authored
(While auditing for #2800)
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
-
- 03 Feb, 2021 1 commit
-
-
Poul-Henning Kamp authored
-
- 02 Feb, 2021 6 commits
-
-
Nils Goroll authored
In any good relationship, one should be clear about expectations. And VCL authors want to know what VCC wants to hear, so tell them. ;)
-
Nils Goroll authored
besides the incorrect bits we want to check for. Ref c4ec4712 Exposed by #3163
-
Nils Goroll authored
as requested by phk. I found no way to avoid having to escape the backslashes because python, even for uninterpolated ''' long strings, sees them as line continuations. The generated output is identical except for two comments (in the code and the code output by the code). --- ./lib/libvcc/vcc_fixed_token.o.c 2021-02-02 10:40:03.725244373 +0100 +++ ./lib/libvcc/vcc_fixed_token.c 2021-02-02 10:52:04.921259718 +0100 @@ -834,10 +834,7 @@ "uct vre **, const char *);\nvoid VPI_re_fini(struct vre *);\n" ); VSB_cat(sb, "\n"); - - /* ../include/vcc_assert.h */ - - VSB_cat(sb, "/* ---===### include/vcc_assert.h ###===--- */\n\n"); + VSB_cat(sb, "/* ---===### vgc asserts (generate.py) ###===--- */\n\n"); VSB_cat(sb, "#define assert(e)\t\t\t\t\t\t\t\\\ndo {\t\t\t\t" "\t\t\t\t\t\\\n\tif (!(e)) {\t\t\t\t\t\t\t\\\n\t\tVPI_Fail(__func" "__, __FILE__, __LINE__, #e);\t\t\\\n\t}\t\t\t\t\t\t\t\t\\\n"
-
Nils Goroll authored
to split the output formattings from emit_file() from reading the file The produced output lib/libvcc/vcc_fixed_token.c is identical before/after.
-
Poul-Henning Kamp authored
Fixes #3509
-
Poul-Henning Kamp authored
-
- 01 Feb, 2021 4 commits
-
-
Nils Goroll authored
We wrap VAS_Fail() as VPI_Fail() and add an assert() macro to the Varnish Generated C (VGC) code. This assert() definition is basically a copy of that in vas.h, but deliberately added to a source file which is only used by generate.py for VGC, such that this slightly different definition be only visible to VGC. I also pondered the option to include VCL source information in VPI_Fail: By using the information updated by VPI_count(), we could have that, but as the assert is, for now, intended only to ensure correctness of VCC and core VRT code, I decided against this complication. With assert() in place for VGC, we arm the assertions from 75acb5cc
-
Nils Goroll authored
It seems they do not parse attributes and how I read --macro-file-builtins they just define them to NIL.
-
Nils Goroll authored
How 16, you ask? Consider alignment...
-
Dridi Boukelmoune authored
One of the VCL 4.1 changes was to make the protocol read-only, which we've successfully done for all variables except resp.proto that kept the exact same definition for both 4.0 and 4.1 versions, despite having distinct definitions.
-
- 31 Jan, 2021 2 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
How I added generation of the assertion code was motivated by how I wanted to lay out more changes in that area later, but generating parts of the function body before the header turned out to not help clarity. Ref 75acb5cc
-
- 30 Jan, 2021 2 commits
-
-
Nils Goroll authored
Bail out upon first error, as for the non-recursive case.
-
Nils Goroll authored
in the course of #3163 we want to add a preamble to VCL subs, which, ideally, would perform as many checks based on constants as possible. This is a first step towards such checks: We add a commented-out assert() on ctx->method for built-in subs only. To add the same for custom subs, we will need the okmask from #3163, for which I would first want to coordinate with phk. Also, I would want to coordinate with him on arming the assertion, as there might be a good reason why assert() is not yet defined for vgc (it is already used in unused macros, though). Having assertions would help humans, flexelint and compilers alike. Until armed, the assertion helps humans at least. The resulting vgc looks like this: void v_matchproto_(vcl_func_f) VGC_function_vcl_backend_error(VRT_CTX) { // assert(ctx->method == (VCL_MET_BACKEND_ERROR)); /* ... from ('Builtin' Line 165 Pos 23) */
-
- 29 Jan, 2021 3 commits
-
-
Poul-Henning Kamp authored
-
Poul-Henning Kamp authored
Add a VCL_BLOB for a connection preamble to struct vrt_backend (mortally offending FlexeLint in the process.)
-
Poul-Henning Kamp authored
-
- 28 Jan, 2021 1 commit
-
-
Nils Goroll authored
Quote more. Do not quote too much Ref da2409c3
-