[Bug binutils/30561] conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 --- Comment #5 from Stas Sergeev --- OK, I use the work-around you suggested. Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30561] conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 --- Comment #4 from Stas Sergeev --- (In reply to Nick Clifton from comment #3) > Well for example, objcopy has no way of determining whether the input binary > contains code, data, or something else. So it is not at all obvious which > section(s) should be used to contain the input. AFAIK you can use --rename-section if you don't want to have the default .data. man page even has an example of how to do this. > Plus there is nothing to > indicate if there are any alignment requirements for the input, I think --set-section-alignment can be used to set an alignment of a desired section. Sure thing with incbin you can do lots of fancy tricks, define more symbols than objcopy would, and so on. But objcopy seems to cover most of the basic needs. > But my feeling is that fixing it is a very low priority, at least at the > moment. It breaks under cygwin (not only under cygwin), where PE is a default. So while a very minor problem under linux, its quite a problem under windows. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30561] conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 --- Comment #3 from Nick Clifton --- (In reply to Stas Sergeev from comment #2) > Still would you mind clarifying why > "There is just not enough information in the input format to enable a > proper conversion"? Well for example, objcopy has no way of determining whether the input binary contains code, data, or something else. So it is not at all obvious which section(s) should be used to contain the input. Plus there is nothing to indicate if there are any alignment requirements for the input, or symbols that should reference it, or relocations that are needed to update it and so on. > If this is true, then I'll just write > the script. If not true - I would expect > the bugfix is needed. :) > Please note that converting the same > to ELF works well. In this particular > case it seems likely the PE header got > messed up. OK, so yes, there probably is a bug, or at least an invalid assumption, in the code that generates the PE header. But my feeling is that fixing it is a very low priority, at least at the moment. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30561] conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 --- Comment #2 from Stas Sergeev --- Hi Nick, thanks for a suggestion. Its not as simple, at the very minimum I'll need to generate with some script such .S files, so that they provide the needed symbols, like _binary__etc_resolv_conf_start _binary__etc_resolv_conf_end _binary__etc_resolv_conf_size. I know how to do that. Still would you mind clarifying why "There is just not enough information in the input format to enable a proper conversion"? If this is true, then I'll just write the script. If not true - I would expect the bugfix is needed. :) Please note that converting the same to ELF works well. In this particular case it seems likely the PE header got messed up. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30561] conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Stas, To be honest I am not at all surprised by this. Converting arbitrary binary input into a specific file format is never going to work well. There is just not enough information in the input format to enable a proper conversion. Instead may I suggest an alternative, using the assembler's .incbin directive, like this: $ cat tst.s .data .incbin "/etc/resolv.conf" $ as tst.s -o tst.o $ file tst.o tst.o: Intel amd64 COFF object file, no relocation info, no line number info, not stripped, 3 sections, symbol offset=0x43c, 8 symbols, 1st section name ".text" $ objdump -P header tst.o tst.o: file format pe-x86-64 File header not present Image Header (at offset 0): Machine Number: 0x8664 - AMD64 Number of sections: 3 Time/Date:- not set Symbol table offset: 0x00043c Number of symbols:8 Optional header size: 0 Flags:0x0005 - RELOCS STRIPPED,LINE NUMS STRIPPED Optional header not present Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
