My latest error

[Kurt Miller]

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