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] |
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] |