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