Allow Java's ELF symtab reader to use separate debuginfo files

[Andrew Haley]

Kelly O'Hair wrote:
> Andrew John Hughes wrote:
>> 2009/12/9 Andrew Haley <aph at redhat.com>:
>>> This is https://bugzilla.redhat.com/show_bug.cgi?id=541548
>>> The symptom is that jmap doesn't work because target libraries are stripped.
>>> The fix is to allow the symtab reader to use the separate debuginfo files
>>> that are available for all (AFAIK) GNU/Linux distributions.
>>>
>>> I'll commit this to the IcedTea repo, with a view to pushing it upstream
>>> to OpenJDK if it works on all distros.
>>>
>>> Andrew.
>>>
>> It would be good to see this upstream.  The obvious compatibility
>> issue I can see is hardcoding /usr/lib/debug.  Passing that in from
>> the Makefile, thus allowing to be overridden if necessary, might be
>> better.
>> i.e.
>>
>> static const char debug_file_directory[] = "/usr/lib/debug";
>>
>> becomes
>>
>> #ifndef DEBUG_FILE_DIRECTORY
>> #define DEBUG_FILE_DIRECTORY "/usr/lib/debug"
>> #endif
>>
>> with apppropriate logic in the OpenJDK makefile(s).
>>
>> Only other comment is that your ChangeLog should refer to openjdk, not
>> openjdk-ecj as we want this for all builds. The patch itself is
>> correct, it's just the ChangeLog.
>>
>> Redirecting this mail to the HotSpot and serviceability lists rather
>> than tl as it concerns the serviceability tools in HotSpot.
> 
> Is there some other way than baking in 256 hex constants into our sources?

I'm sure it's perfectly possible to generate the CRC-32 tables at runtime.
However, the CRC function is defined in terms of this exact source code,
see http://sourceware.org/gdb/current/onlinedocs/gdb/Separate-Debug-Files.html#Separate-Debug-Files

> Why can't this logic be in a system include file somwehere?

Apart from "because it isn't", I can think of no good reason.  Clearly
there should be a common API for this stuff, but it is spread around
various tools and libraries with licences we can't use, such as GPLv3+.

Andrew.