Re: libgcj/341

[Jeff Sturm <jeff dot sturm at appnet dot com>]

The following reply was made to PR libgcj/341; it has been noted by GNATS.

From: Jeff Sturm <jeff.sturm@appnet.com>
To: Bryce McKinlay <bryce@albatross.co.nz>
Cc: aph@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: libgcj/341
Date: Fri, 06 Oct 2000 10:36:20 -0400

 Bryce McKinlay wrote:
 > >  It appears something is broken in dladdr() anyway.  The a,b,c methods should
 > >  have global symbols, so dladdr() isn't resolving to the closest symbol, it falls
 > >  all the way down to __frame_state_for instead.
 > 
 > Thats what I thought, but Ulrich's terse reply implied that the "__frame_state_for"
 > result is expected and has some sort of cosmic significance. To me, dladdr()'s
 > behaviour is not useful in this case.
 
 It's also wrong:
 
 > $ nm ./st | sort | more
 > 08048ed0 ? _init
 > 08049160 T _start
 > 08049184 t gcc2_compiled.
 > 08049190 t __do_global_dtors_aux
 > [...]
 > 0804b270 t execute_cfa_insn
 > 0804b6d0 T __frame_state_for
 > 0804b870 T __10StackTrace
 > 0804b890 T main__10StackTracePt6JArray1ZPQ34java4lang6String
 > 0804b8b0 T a__10StackTrace
 > 0804b8d0 T b__10StackTrace
 > 0804b8f0 T c__10StackTrace
 
 The PR says:
 
 > at 0x0804b8ab: __frame_state_for (./st)
 
 There are two other global symbols between that address and that symbol,
 according to the output of "nm".  The dladdr() function is intended to return
 the nearest symbol to the given address, if it is a valid address at all.
 
 My guess is that dladdr() misses a__10StackTrace etc. because they aren't
 referenced outside this module, so the dynamic linker doesn't have to do
 anything with them.
 
 It would be nice to have a simple test case for this.  I'm not running RH 7,
 yet...
 
 --
 Jeff Sturm
 jeff.sturm@commerceone.com