This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] msymbol.size
- From: mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
- To: ezannoni at redhat dot com, mec dot gnu at mindspring dot com
- Cc: brobecker at gnat dot com, gdb-patches at sources dot redhat dot com
- Date: Tue, 11 Nov 2003 11:29:51 -0500 (EST)
- Subject: Re: [rfc] msymbol.size
[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.
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
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.
Michael C