Kelly O'Hair wrote: > Andrew John Hughes wrote: >> 2009/12/9 Andrew Haley <[email protected]>: >>> 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.
