On Thu, 30 Oct 2008 13:01:08 -0500
Rob Landley <[EMAIL PROTECTED]> wrote:
Hi people,
> On Wednesday 29 October 2008 17:05:54 Bernhard Reutner-Fischer wrote:
> > On Thu, Oct 30, 2008 at 10:06:45AM +1300, Jeremy Bowen wrote:
> > >On Monday 20 October 2008 5:54:14 pm Rob Landley wrote:
<snipp>
> > >OK after a lot of effort re-validating my toolchain, I'm now
> > >certain the problem occurs within uClibc and not busybox.
> > >
> > >Specifically ./libc/misc/regex/regex_internal.c on line 703/4 >> <<
> > >==============================================
> > >#endif /* RE_ENABLE_I18N */
> > > {
> > > int c = pstr->raw_mbs[pstr->raw_mbs_idx + offset -
> > > 1]; if (pstr->trans)
> > > c = pstr->trans[c];
> > >==============================================
> > >
> > >However I'm now very nervous about my C compiler....
> > >
Depends on which version you are using. From where did you compile GCC?
There are quite some necessary patches needed at
http://avr32linux.org/twiki/bin/view/Main/GccPatches
The AVR32 fork() of Buildroot should generate a proper GCC, if it does
not then I am interested in fixing it.
> > >I don't believe uClibc is actually broken because changing the
> > >above code
> > > to
> > >
> > > if (pstr->trans)
> > >+ {
> > >+ dprintf(2, "Hello");
> > > c = pstr->trans[c];
> > >+ }
> > >
> > >eliminates the segfault behaviour even though "Hello" is never
> > >printed.
> > >
Hmmm, not good. Do you have any chance of making a small test case?
> > >The fact that the expression evaluates to false and the code
> > >continues on
> > > OK makes me believe there is a problem with compiler optimisation
> > > or something else, which I'm at a loss to explain at the moment.
> > >
> > >The code looks perfectly legal and simply bracketing the statement
> > >in the
> > > 'if' doesn't help (but adding dprintf does).
> > >
> > >It has to be a compiler bug right ??
> >
> > Sounds a bit like it is.
> > sprinkle some __asm__("# 1"); round the spot to see what the
> > compiler generates there. Build this file with -O0 (either via
> > __attribute__((optimize(0))) or by setting e.g.
> > CFLAGS-regex_internal.os) if that works then reduce the spot that
> > is miscompiled as described somewhere in
> > http://gcc.gnu.org/bugs.html and report it in bugzilla.
>
> If you understand avr32 assembly, look at the assembly output via
> "objdump -d" or in gdb.
>
I understand AVR32 assembly, so I just need details about toolchain
used, which uClibc version and application to trigger this segfault.
My 0.02 € is that ./libc/misc/regex/regex_internal.c is the file which
gets compiled wrong?
> (Sometimes adding dprintf() will fix something when the stack is
> getting stomped somewhere, but that doesn't look like it's the case
> here...)
>
Or that the compiler just does some wrong assumptions when optimizing,
we've had that in the early stages, but I thought all those were found
and nuked... ™
--
Best regards,
Hans-Christian Egtvedt
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
