[parisc-linux] Re: Need help writing register consistency test?

[parisc-linux] Re: Need help writing register consistency test?

[John David Anglin]

> > > Why isn't this the debug ld.so?
> > 
> > dave@gsyprf11:~/gcc-4.0$ ll /usr/lib/debug/ld.so.1
> > lrwxr-xr-x  1 root root 11 Sep 12 22:15 /usr/lib/debug/ld.so.1 ->
> ld-2.3.2.so
> 
> Yes, but that isn't what you are using.

Doh, I'm using the default set by ld.  This can be changed using
the --dynamic-linker file option.

> > Makes life difficult, hey :(  However, I'm only seeing this stuff
> > with 64-bit kernels.
> 
> Or is it that only 64-bit boxes are fast enough to expose a race
> condition?

I doubt it's a speed issue as my c3750 has a faster cpu.  However,
it could be a SMP problem.

> > > So you are saying that the code should have given that value, but
> > > something corrupted the value before it was used?
> > 
> > Yes.
> 
> That is a very interesting hypothesis. It looks like the bug I used to
> track down with r19 corruption only under certain return paths of fork
> in the kernel. I'll be frank it takes some serious debugging.
> 
> -- Help Needed! --
> 
> There are only 235 syscalls, some of which don't need to be tested, only
> a small fraction could be tested with some special program? A program
> that would check for register value consistency across the call?
> This would have caught our r19 corruption through fork, perhaps there
> are other temp register uses that clobber a single register? It would be
> a starting place.

I'm not sure that this is a syscall problem although it might be.  There
weren't any syscalls between the load for r3 and when it was used as far
as I can tell.  So, if this is a syscall problem, it would have to be a
syscall that was done in a signal handler.  The difficulty in writing
a program such as that suggested above is that it has to somehow test
all the return paths in the kernel for each syscall.

Had another SEGV building GCC last night of gsyprf11.

I certainly agree that this type of problem needs some serious debugging.
I think logging of SEGVs is somewhat broken.  It looks like kernel logging
stops when /var fills up and doesn't automatically restart when the problem
is cleared.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: Need help writing register consistency test?

[Randolph Chung]

> I'm not sure that this is a syscall problem although it might be.  There
> weren't any syscalls between the load for r3 and when it was used as far
> as I can tell.  So, if this is a syscall problem, it would have to be a
> syscall that was done in a signal handler.  The difficulty in writing
> a program such as that suggested above is that it has to somehow test
> all the return paths in the kernel for each syscall.

yeah, possibly it's something in one of the interruption paths.

Dave, do you have any comments on this:
http://marc.theaimsgroup.com/?l=linux-ia64&m=109507921717647&w=2

do you think this could be causing problems for us too? (do you do any
stracing/gdb during your tests?)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: Need help writing register consistency test?

[John David Anglin]

> Dave, do you have any comments on this:
> http://marc.theaimsgroup.com/?l=linux-ia64&m=109507921717647&w=2
> 
> do you think this could be causing problems for us too? (do you do any
> stracing/gdb during your tests?)

No, but the symptoms seem similar.  I had one failure in the return
from pipe.  It's possible that some of the gcj SEGVs follow a pipe
syscall.

The fix was to compile with -fno-optimize-sibling-calls.  In recent
versions of GCC, we allow sibcalls for 32-bit code but not for
64-bit code.  This is because the arg pointer isn't a fixed register
in the 64-bit runtime and because the linker does a crappy job of
stub placement.

In spite of the fact that sibcalls are not ok in the 64-bit runtime,
I think there are still situations where gcc will generate sibcalls.
For example, in gcc 4.0, the gcc.dg/sibcall-[12].c tests now pass.
Self-recursion tail calls are optimized for all targets regardless of
the presence of sibcall patterns.

The ia64 GCC fix was to return false in ia64_function_ok_for_sibcall
if the function has the syscall_linkage attribute.  As I noted above,
we always return false on hppa64.  So, if we have a sibcall problem,
it has to be in a self-recursion tail call.

I'm fairly sure that sibcalls have always been disabled on hppa64
in the released versions of GCC.  I'm not sure about 3.0.4.  Alan
Modra was experimenting with them.

Are we using the syscall_linkage attribute?  This could be an issue
on the 32-bit port where sibcalls are enabled.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux