[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 Ed Maste changed: What|Removed |Added Summary|objcopy in 11 appears to|objcopy (elfcopy) in 11 |have a regression compared |appears to have a |to the version in 10|regression compared to the ||version in 10 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 Mitchell horne changed: What|Removed |Added CC||mhorne...@gmail.com --- Comment #3 from Mitchell horne --- (In reply to pete from comment #2) Here's the readelf section information on the file you provided: $ readelf --sections ipxe.pxe.tmp File: ipxe.pxe.tmp There are 20 section headers, starting at offset 0x702650: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .prefix PROGBITS 000134 000cb1 00 WAX 0 0 1 [ 2] .text16.early PROGBITS 000df0 ee 00 WAX 0 0 2 [ 3] .text16.late PROGBITS00f0 000ee0 0007f2 00 WAX 0 0 16 [ 4] .data16 PROGBITS 0016e0 000150 00 WA 0 0 16 [ 5] .bss.data16 NOBITS 0150 0cb780 003040 00 WA 0 0 16 [ 6] .textdata PROGBITS 001830 0c9ec8 00 WAX 0 0 4 [ 7] .bss.textdata NOBITS 000c9f00 0cb780 0a5580 00 WA 0 0 128 [ 8] .zinfoPROGBITS 0cb6f8 80 00 A 0 0 1 [ 9] .debug_info PROGBITS 0cb778 398f31 00 0 0 1 [10] .debug_abbrev PROGBITS 4646a9 054828 00 0 0 1 [11] .debug_arangesPROGBITS 4b8ed1 008e50 00 0 0 1 [12] .debug_line PROGBITS 4c1d21 059425 00 0 0 1 [13] .debug_strPROGBITS 51b146 05a0b9 01 MS 0 0 1 [14] .debug_frame PROGBITS 575200 02ec7c 00 0 0 4 [15] .debug_locPROGBITS 5a3e7c 15183d 00 0 0 1 [16] .debug_ranges PROGBITS 6f56b9 00ced0 00 0 0 1 [17] .shstrtab STRTAB 702589 c5 00 0 0 1 [18] .symtab SYMTAB 702970 01af40 10 19 4079 4 [19] .strtab STRTAB 71d8b0 01ebe8 00 0 0 1 It appears that .bss.data16 and .bss.textdata overlap with .debug_info and this is causing them to be moved. According to the ELF specification, "Sections in a file may not overlap. No byte in a file resides in more than one section" [1]. So whatever program is generating your ELF file is doing so incorrectly. Although GNU objcopy is able to ignore this when generating a binary file, it will adjust the section offsets similar to elftoolchain objcopy when performing other operations (e.g. objcopy -R .zinfo ipxe.pxe.tmp). However, I'm not sure why this would be causing you problems either way. When converting an ELF file to binary, sections with NOBITS type are ignored since they take up no actual space in the file itself. This is the case regardless of which implementation of objcopy you use. Perhaps elftoolchain has a different bug in the binary creation procedure, but to find that you would need to provide additional info on how the binary output file is unusable. The simplest workaround (if you still need it at this point) is to use the GNU version of objcopy provided in the binutils package. [1] http://www.skyfree.org/linux/references/ELF_Format.pdf -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 --- Comment #5 from jack --- CC:proposed path, testcase, etc. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 jack changed: What|Removed |Added CC||two...@yahoo.com Attachment #189987||maintainer-approval+ Flags|| --- Comment #4 from jack --- Created attachment 189987 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189987&action=edit File:user/password -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 Oleksandr Tymoshenko changed: What|Removed |Added CC||go...@freebsd.org Attachment #189987|0 |1 is obsolete|| -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 --- Comment #6 from Oleksandr Tymoshenko --- The content of attachment 189987 has been deleted for the following reason: spam -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 Gleb Popov changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2414 ||37 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 Michael Brown changed: What|Removed |Added CC||mc...@ipxe.org --- Comment #7 from Michael Brown --- I have updated the iPXE build process to place the (meaningless) load addresses for the various NOLOAD sections earlier than the .zinfo section. This change is in commit https://github.com/ipxe/ipxe/commit/fe52f8e8b and eliminates the harmless "moving loadable section" warning. However, there seems to be something else very broken in the elftoolchain implementation of "objcopy -O binary". Extracting a single section using e.g. objcopy -O binary -j .zinfo bin/ipxe.pxe.tmp bin/ipxe.pxe.zinfo works as expected. Extracting multiple sections using e.g. objcopy -O binary -R .zinfo bin/ipxe.pxe.tmp bin/ipxe.pxe.bin or even just objcopy -O binary bin/ipxe.pxe.tmp wtf produces a binary file with no discernible relation to the input. It looks vaguely as though objcopy is ignoring the load addresses and just placing the sections semi-randomly within the output file. For now, I've modified the iPXE build process to check for the elftoolchain version of objcopy and refuse to use it (https://github.com/ipxe/ipxe/commit/1fea8ce06). It would be good to get a proper fix for this, if anyone has time to dig into how the elftoolchain objcopy is handling "-O binary". Michael -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 --- Comment #8 from Ed Maste --- It appears that each section is copied to the output binary at an offset specified by the section's Addr, in an some (unspecified) order - i.e., both .textdata and .zinfo specify an address of 0, and the output is .textdata overlaid with .zinfo. [ 6] .textdata PROGBITS 001830 0c9ec8 00 WAX 0 0 4 [ 8] .zinfoPROGBITS 0cb6f8 80 00 A 0 0 1 $ readelf -x .zinfo ipxe.pxe.tmp | less Hex dump of section '.zinfo': 0x 434f5059 b10c 1000 COPY ... 0x0070 4157 db03 1000 ADDW $ readelf -x .textdata ipxe.pxe.tmp Hex dump of section '.textdata': 0x 8b542404 8b042489 02896204 .T$...$...b. ... 0x0070 6883 0089c1ba 3f00 e8cac002 h...?... 0x0080 00c9c353 89c389d0 0fb75260 895314c6 ...S..R`.S.. 0x0090 431800ba 0100 e8adab01 00b9fff0 C... ... 0x000c9ec0 d5570300 dd520300 .W...R.. $ hexdump -Cv output 43 4f 50 59 00 00 00 00 b1 0c 00 00 10 00 00 00 |COPY| ... 0070 41 44 44 57 db 03 00 00 10 00 00 00 00 00 00 00 |ADDW| 0080 00 c9 c3 53 89 c3 89 d0 0f b7 52 60 89 53 14 c6 |...S..R`.S..| ... 000c9ec0 d5 57 03 00 dd 52 03 00 |.W...R..| 000c9ec8 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 --- Comment #9 from Michael Brown --- (In reply to Ed Maste from comment #8) Thanks for taking a look. The multiple sections all with virtual memory addresses of zero are correct: there are genuinely multiple disjoint address spaces at runtime. For example: the real-mode code segment (.text16) and real-mode data segment (.data16) may be placed arbitrarily in base memory once loaded, and virtual addresses within those segments are just 16-bit offsets from the start of each segment, dereferenced against %cs or %ds as applicable. The load memory addresses (LMA) that we create within the ELF file represent the offsets at which we expect each section to appear in the file generated by "objcopy -O binary". Looking at the output of "objdump -h bin/ipxe.dsk.tmp" I see e.g.: objdump -h bin/ipxe.dsk.tmp bin/ipxe.dsk.tmp: file format elf32-i386-freebsd Sections: Idx Name Size VMA LMA File off Algn 0 .prefix 090d 0154 2**0 CONTENTS, ALLOC, LOAD, CODE ... 7 .textdata 000ce040 1370 14c0 2**5 CONTENTS, ALLOC, LOAD, CODE which correctly shows that we have (at least) two sections with a VMA of , but that .prefix should appear at offset and .textdata at offset 1370 within the "-O binary" output file based on the LMA of each section. The binutils objcopy does behave this way: it will use the load memory addresses as the file offsets for "-O binary" (with the first byte in the output file corresponding to the lowest load memory address present in the output). The binutils objcopy behaviour seems correct to me: since "-O binary" is intended to create a raw binary image then the LMA (rather than the VMA) is the relevant value for the offset within this binary image. Could the elftoolchain objcopy be made to match this behaviour? Thanks, Michael -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 --- Comment #10 from Michael Brown --- (In reply to Ed Maste from comment #8) >From looking at elfcopy/binary.c and its create_binary() function: it appears that elfcopy will use sh_offset to calculate the position within the final binary file (rather than the LMA or even the VMA). Since sh_offset is meaningless once the ELF headers have been stripped away, this behaviour is provably incorrect for anything other than extracting a single section via "-j ". Building elfcopy from source confirms this behaviour from the current code. So, we have three possible behaviours: 1. binutils objcopy Uses the section LMA to determine the offset within the output file. As above, I would say that this behaviour is correct. 2. FreeBSD objcopy as present in binary distributions Uses the section VMA to determine the offset within the output file. As above, I would say that this behaviour is wrong. 3. FreeBSD objcopy as built from source Uses the section sh_offset to determine the offset within the output file. This behaviour is very definitely wrong. I am puzzled why I get different behaviour from the FreeBSD binary and source distributions, particularly since the use of sh_offset appears to have been present since 2010. Michael -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316 VinÃcius Zavam changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2546 ||00 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"