On Thu, 2015-05-14 at 16:59 -0400, Kurt Miller wrote: > The debug symbol logic works in several places prior to it failing. When > it does fail it fails with: > > /usr/bin/objcopy: libinstrument.debuginfo: Invalid operation > > I can manually reproduce the 'Invalid operation' error if I attempt to > do --add-gnu-debuglink on a binary that already has gnu-debuglink set. > > When I read the build logs I don't see two calls to set gnu-debuglink, > however it still fails with 'Invalid operation'. Very strange. Checking > with readelf -S I can see that libinstrument.so does have gnu-debuglink > set after the build fails.
Hexdump of libinstrument.so at the address for gnu-debuglink shows it imported the debuglink from libjli_static: 00076870 00 00 6c 69 62 6a 6c 69 5f 73 74 61 74 69 63 2e |..libjli_static.| 00076880 64 65 62 75 67 69 6e 66 6f 00 00 9e 91 f0 00 2e |debuginfo.......| So it is failing because it is already set via the libjli_static.a that was linked in: Linking libinstrument.so /usr/bin/gcc -shared <snip> -Xlinker --whole-archive /home/truk/jdk/jdk8/build/bsd-x86_64-normal-server-release/jdk/objs/libjli_static.a -Xlinker --no-whole-archive <snip> The use of a static libjli.a is somewhat historical. I recall there was some problem with it back in 1.5 or 1.6 and using a static version was a work-around. Perhaps it was back when OpenBSD and FreeBSD didn't have $ORIGIN support in our runtime linkers. I see two ways to fix this. Retest building with a dynamic libjli or modify the debuglink make rules to not put debuglink on static libs (may be a good idea either way). -Kurt
