Allow Java's ELF symtab reader to use separate debuginfo files
aph at redhat.com
Wed Dec 9 10:10:12 PST 2009
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.
>> 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
>> static const char debug_file_directory = "/usr/lib/debug";
>> #ifndef DEBUG_FILE_DIRECTORY
>> #define DEBUG_FILE_DIRECTORY "/usr/lib/debug"
>> 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,
> 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+.
More information about the hotspot-dev