Nick Clifton <[EMAIL PROTECTED]> writes: > Hi Dave, > > > I think there's a bug in the way objcopy handles R_386_32 (absolute > > 32-bit) relocation entries when translating from elf to pe-i386 > > (windows) object files. > > > > The symptom is that R_386_32 relocations in elf get translated into > > DIR16 entries in the pe-i386. (Or perhaps just not translated, since I > > think DIR16 is numerical value 1, which I think is the same numerical > > value as R_386_REL, and possibly also the same value as bfd uses > > internally, though that part is pure speculation from a very quick > > look at the source.) > > Your speculation is correct. Objcopy does not perform *any* > translation of relocations. This is why it very rarely works when > translating object files.
Is this considered a bug, or a design compromise, in objcopy ? Ie is it something that will get fixed if someone cares enough, or is it not something that it was ever intended to do (and so a patch would be rejected) ? There did seem to be mechanisms in place to be able to convert relocations from input format to canonical bfd, and then to target format. But they just don't seem to get called. > Your best bet is to link the elf32-i386 object files into a fully > linked program first and then use objcopy to translate it into a > pe-i386 executable. I did find a workaround - since it's my own program that's generating the elf, I can just generate an incorrect elf file with the coff relocation tags, and then after the objcopy, I end up with an (apparently) correct pe-coff object file. Thanks dd -- Dave Denholm <[EMAIL PROTECTED]> http://www.esmertec.com _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
