Date: Tue, 09 Jan 2018 16:35:53 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10 Message-ID: <bug-216316-29464-p86H85Gk8D@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-216316-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-216316-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216316 Mitchell horne <mhorne063@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mhorne063@gmail.com --- Comment #3 from Mitchell horne <mhorne063@gmail.com> --- (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 Type Addr Off Size ES Flg Lk I= nf Al [ 0] NULL 00000000 000000 000000 00 0 = 0=20 0 [ 1] .prefix PROGBITS 00000000 000134 000cb1 00 WAX 0 = 0=20 1 [ 2] .text16.early PROGBITS 00000000 000df0 0000ee 00 WAX 0 = 0=20 2 [ 3] .text16.late PROGBITS 000000f0 000ee0 0007f2 00 WAX 0 = 0 16 [ 4] .data16 PROGBITS 00000000 0016e0 000150 00 WA 0 = 0 16 [ 5] .bss.data16 NOBITS 00000150 0cb780 003040 00 WA 0 = 0 16 [ 6] .textdata PROGBITS 00000000 001830 0c9ec8 00 WAX 0 = 0=20 4 [ 7] .bss.textdata NOBITS 000c9f00 0cb780 0a5580 00 WA 0 = 0 128 [ 8] .zinfo PROGBITS 00000000 0cb6f8 000080 00 A 0 = 0=20 1 [ 9] .debug_info PROGBITS 00000000 0cb778 398f31 00 0 = 0=20 1 [10] .debug_abbrev PROGBITS 00000000 4646a9 054828 00 0 = 0=20 1 [11] .debug_aranges PROGBITS 00000000 4b8ed1 008e50 00 0 = 0=20 1 [12] .debug_line PROGBITS 00000000 4c1d21 059425 00 0 = 0=20 1 [13] .debug_str PROGBITS 00000000 51b146 05a0b9 01 MS 0 = 0=20 1 [14] .debug_frame PROGBITS 00000000 575200 02ec7c 00 0 = 0=20 4 [15] .debug_loc PROGBITS 00000000 5a3e7c 15183d 00 0 = 0=20 1 [16] .debug_ranges PROGBITS 00000000 6f56b9 00ced0 00 0 = 0=20 1 [17] .shstrtab STRTAB 00000000 702589 0000c5 00 0 = 0=20 1 [18] .symtab SYMTAB 00000000 702970 01af40 10 19 4= 079=20 4 [19] .strtab STRTAB 00000000 71d8b0 01ebe8 00 0 = 0=20 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 m= ay not overlap.=20=20 No byte in a file resides in more than one section" [1]. So whatever progra= m is generating your ELF file is doing so incorrectly. Although GNU objcopy is able to igno= re 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. Wh= en converting an ELF file to binary, sections with NOBITS type are ignored since they take u= p no actual space in the file itself. This is the case regardless of which implementation of objcopy you use.=20 Perhaps elftoolchain has a different bug in the binary creation procedure, = but to find that=20 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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-216316-29464-p86H85Gk8D>