This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH V2 6/8] bpf: adjust GCC testsuite to eBPF limitations


    [...]
    > 	* gcc.dg/Wframe-larger-than-2.c: Likewise.
    > 	* gcc.dg/Wframe-larger-than.c: Likewise.
    > 	* gcc.dg/Wrestrict-11.c: Likewise.
    So I think we probably want an effective target check for indirect calls
    rather than checking explicitly for ebpf in all these files.
    
Ok, will introduce it.

    It also seems like rather than checking for ebpf on files with large
    stacks, we should be using the generic mechanisms to defined the allowed
    size of the stack (mentioned in prior review) & mark test which use too
    much space.  This would almost certainly help other embedded targets as
    well.
    
I first thought about doing that, but hesitated when I realized it would
require to alter existing tests in no trivial ways: will the test still
effectively test whatever it is supposed to test, after the size of an
array is changed, for example?

    Not sure the best way to deal with too many arguments.  I suspect we
    want an efffective target check for that.  Keeping this up-to-date will
    be painful as people write more tests.
    
Yeah, that won't be fun :(

      /* Copyright (C) 2000, 2003 Free Software Foundation */
    >  __complex__ long long f ()
    > diff --git a/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
    > b/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
    > index be0bdcf7631..9f6bd0af2e5 100644
    > --- a/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
    > +++ b/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
    > @@ -3,6 +3,7 @@
    >  /* { dg-skip-if "too much code for pdp11" { "pdp11-*-*" } } */
    >  /* { dg-xfail-if "PR36698" { spu-*-* } { "-O0" } { "" } } */
    >  /* { dg-skip-if "" { m32c-*-* } } */
    > +/* { dg-skip-if "jumps too far for eBPF" { bpf-*-* } } */
    >  /* { dg-timeout-factor 4.0 } */
    Jumps too far is probably an indication you need to fix something in
    your port.  Though I guess its OK if you're never going to support far
    away targets.

The reasons for this are that eBPF doesn't have indirect jump
instructions, and the direct jump instruction's displacement is a signed
PC-relative 16-bit offset, in 64-bit word units.

So, unless the compiler gets able to generate a "chain" of direct jumps
to reach the destination (that would be a fun hack :D) the range for
branches is severely limited.

    > diff --git a/gcc/testsuite/gcc.c-torture/compile/20101217-1.c
    > b/gcc/testsuite/gcc.c-torture/compile/20101217-1.c
    > index c4eef0ed464..cd902afe709 100644
    > --- a/gcc/testsuite/gcc.c-torture/compile/20101217-1.c
    > +++ b/gcc/testsuite/gcc.c-torture/compile/20101217-1.c
    > @@ -1,3 +1,5 @@
    > +/* { dg-skip-if "no usable stdio.h for eBPF" { bpf-*-* } } */
    I think this is only to get the printf prototype.  I suspect you could
    just provide a suitable prototype and drop the #include <stdio.h>.
    
Nice, will do just that.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]