Compiler bug: "Unexpected header type" about p4c HOT 8 CLOSED

v1model is not documented properly, but the expectation is that the hdr struct (called h in this program) would only contain headers or stacks. It's equivalent to the P4-14 collection of all possible headers. We should provide a better error message, though.

from p4c.

I see. Is the right solution to restrict v1model? Or could one improve the compiler so it supports all types?

from p4c.

v1model was written to allow P4-14 programs to be translated to P4-16. The converter should never generate programs that crash the compiler. However, today v1model is the only model which can be executed by the behavioral model simulator, for both P4-14 and P4-16 programs, so we also use it for testing the compiler using P4-16 programs.

If we want to program v1model directly we have to document it better and make the behavioral model back-end p4c-bm-ss more robust. The long term plan is to have a new standard architecture model and back-end, which would make v1model obsolete. How much we invest in the v1model and p4c-bm-ss back-end depends on how quickly we expect to have the standard architecture model, a corresponding back-end, and support for these in the behavioral model simulator.

from p4c.

Ahh. I misunderstood. Sorry. I thought v1model was the proto-standard architecture. If it's just a shim to allow P4-14 models to import their programs into the P4-16 workchain then these kind of restrictions make total sense.

Thanks for clarifying!

from p4c.

The following similar program causes the compiler to crash with Segmentation fault (core dumped). The problem seems to be that I try to extract a struct in my parser, which the specification of extract forbids.

Maybe an error message would be more graceful than a segmentation fault? Then again, if you don't expect users to write programs against this target manually, it probably does not matter.

#include <core.p4>
#include <v1model.p4>

struct H { };
struct M { };

parser ParserI(packet_in b, out H parsedHdr, inout M meta,
              inout standard_metadata_t standard_metadata)
{
    state start {
                // here I am trying to extract a struct -> segmentation fault
        b.extract(parsedHdr);
        transition accept;
    }
}


control VerifyChecksumI(in H hdr,
                        inout M meta,
                        inout standard_metadata_t standard_metadata)
{
    apply { }
}


control IngressI(inout H hdr,
                 inout M meta,
                 inout standard_metadata_t standard_metadata)
{
    apply { }
}


control EgressI(inout H hdr,
                inout M meta,
                inout standard_metadata_t standard_metadata)
{
    apply { }

}


control ComputeChecksumI(inout H hdr,
                         inout M meta,
                         inout standard_metadata_t standard_metadata)
{
    apply { }
}


control DeparserI(packet_out b, in H hdr)
{
    apply { }
}


V1Switch(ParserI(),
         VerifyChecksumI(),
         IngressI(),
         EgressI(),
         ComputeChecksumI(),
         DeparserI()) main;

from p4c.

I have sent a pull request which fixes these; it includes these examples as tests in p4_16_errors
(Our testing framework does not check the outputs produced by the p4c-bm2-ss compiler - I will file a separate issue with that.)
The compiler should never BUG or segfault.

from p4c.

A segmentation fault can likewise be provoked in the deparser by emitting something that is not a header.

from p4c.

There is a new folder with negative tests for p4c-bm-ss, called testdata/p4_16_bmv_errors. There are three tests for these cases checked-in. (The testing script still does not save reference outputs - so the test would succeed even if the compiler crashes, but I filed issue #96 for this problem.)

from p4c.