[rfc] msymbol.size

Elena Zannoni ezannoni@redhat.com
Tue Nov 11 16:50:00 GMT 2003

Michael Elizabeth Chastain writes:
 > [I added gdb.patches back because we aren't attaching huge files,
 >  so might as well share and enjoy].
 > eza> I did a build w/o your patch but w/ the fprintf. No output :-(
 > eza> A build w/ your patch : still no output from the printf.
 > Okay.  This means that gdb does not use the "texthigh hack" with
 > gcc and /usr/ccs/bin/as.  So, we could do anything we want to
 > msymbol.size and there would be no effect on gdb, as long as gcc
 > is the compiler and /usr/ccs/bin/as is the assembler.
 > Any chance of running the gdb test suite with Sun's compiler?
 > Or even just debugging a 'hello world' program built with Sun's
 > compiler and seeing if the texthigh hack is still used at all.
 > Or even ... running gdb on random Solaris utilities like /usr/bin/ls
 > and seeing what happens.

I don't think I have any machines around here with SUN's compiler on
them. :-( I tried a break main - run on ls and /usr/bin/ccs/help, and
saw no end_symtab printed either. But there is no symbol info there, I

 > eza> So I think that the diff in pthreads.exp could be a fluctuation.
 > eza> Given the roblems with that test.
 > I have run into into similar problems on x86 two or three times.
 > What happens is: pthreads.exp fluctuates because it is a thread test.
 > Sometimes some of the threads are in states that are deterministically
 > bad for gdb.  That is:
 >   when a thread is in state S0, gdb always prints a good backtrace
 >   when a thread is in state S1, gdb always prints a bad backtrace
 >   the thread is in S0 on some runs and S1 on some runs

I've seen that too on Linux.

 > But it is a little dangerous to extrapolate from x86-linux to
 > sparc-solaris so I am hoping to see the gdb.log for the FAIL result
 > in that test.

I hope this was clear, on Solaris I got no differences in the pthreads
tests before and after the patch. There were failures in the
backtraces, but they were failing the same way in both runs. But Joel


 > Michael C

More information about the Gdb-patches mailing list