objcopy --add-gnu-debuglink and relocatable files

[Mike Frysinger]

my reading of the --add-gnu-debuglink option is that it only makes sense when 
used on finally linked executable code (so like ET_DYN or ET_EXEC) ... i hit 
an interesting case where some .o files were globbed in via a zealous script 
and had --add-gnu-debuglink added to each which caused problems with obtuse 
errors in the end when trying to split debug info from real executables.

consider:
$ echo 'int main(){}' > test.c
$ gcc -c test.c
$ objcopy --only-keep-debug test.o test.o.dbg
$ objcopy --add-gnu-debuglink=test.o.dbg test.o
$ readelf -W -S test.o | grep debug
  [ 8] .gnu_debuglink  PROGBITS  0000000000000000 0000a1 000010 00   0   0  1
$ gcc test.o -o test
$ objcopy --only-keep-debug test test.dbg
$ objcopy --add-gnu-debuglink=test.dbg test
objcopy: test.dbg: Invalid operation

this is because in binutils/objcopy.c:copy_object(), the call to 
bfd_create_gnu_debuglink_section() returns NULL (since the section already 
exists in the test ELF by inherting the section from test.o).

perhaps objcopy should reject --add-gnu-debuglink requests for ET_REL 
objects ?  or .gnu_debuglink should be added to the default /DISCARD/ list in 
the default ELF linker scripts ?  or objcopy can test to see if 
the .gnu_debuglink section already exists and if so, simply clobber it, or 
give a more useful error message than just "Invalid operation" ?  or all of 
these ? :)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <https://sourceware.org/pipermail/binutils/attachments/20070707/aaf776a8/attachment.sig>