Request for approval: Allow Java's ELF symtab reader to use separate debuginfo files

[Andrew Haley]

On 01/11/2010 08:36 PM, Tom Rodriguez wrote:
> 
> On Jan 9, 2010, at 3:03 AM, Andrew Haley wrote:
> 
>> On 01/08/2010 07:54 PM, Tom Rodriguez wrote:
>>
>>> I think a better fix is to add the required gHotSpot* symbols to the
>>> mapfile so that they are always exported.
>>
>> I'm not sure this will work on all GNU/Linux distros, since symtabs
>> are routinely removed in their entirety from DSOs.  Is there some
>> logic in the symtab handling to do a look-aside into the dynamic
>> symtab instead of the symtab?

> The solaris libproc does this and I assumed that the linux code we
> wrote would also do this but it looks to me like it doesn't.  I
> don't think it would be hard to add support for parsing the dynsym
> table in build_symtab and it would allow these tools to work if the
> libraries are commonly stripped.  The code could either be modified
> to look for SHT_DYNSYM if SHT_SYMTAB doesn't exist or it could
> always parse both of them.  Something limited like this works ok:

OK, I added that.

I also had to add these

+		_ZTV20ParallelScavengeHeap;
+		_ZTV16GenCollectedHeap;

to the list of exported symbols.  Without this jmap doesn't work.

>> Also, are these the only symbols that are ever looked up by this
>> symtab reader?

> Those are the only ones needed by the core SA functionality.  The
> only thing other symbols are used for is the jstack -m mode that
> dumps mixed Java and native frames ala pstack and adding the
> external debug info reader to support this seems reasonable.

OK.  I guess this will work, but on my x86_64 Linux box ptrace_getregs
is disabled, so jstack -m fails.

There's a new webrev at 
http://cr.openjdk.java.net/~aph/100028-jdk6-webrev-2/

I can confirm that jmap -heap works with and without debuginfo,
whether or not the libraries are stripped.

Andrew.