Re: [rfc] msymbol.size

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

[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