This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

objcopy --add-gnu-debuglink and relocatable files


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

Attachment: signature.asc
Description: This is a digitally signed message part.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]