Bug 216316 - objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10
Summary: objcopy (elfcopy) in 11 appears to have a regression compared to the version ...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-toolchain mailing list
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2017-01-20 15:23 UTC by pete
Modified: 2019-10-23 15:36 UTC (History)
6 users (show)

See Also:


Attachments
File:user/password (deleted)
2018-01-23 09:42 UTC, jack
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description pete 2017-01-20 15:23:35 UTC
I run an iscsi setup booting using ixpe, which I build on the
FreeBSD server. the last few steps of the build do this:

        objcopy -O binary -R .zinfo bin/ipxe.pxe.tmp bin/ipxe.pxe.bin
        objcopy -O binary -j .zinfo bin/ipxe.pxe.tmp bin/ipxe.pxe.zinfo

This runs fine on 10-STABLE, but on 11-STABLE I get these warnings from
the first command:

        objcopy: moving loadable section .bss.data16, is this intentional?
        objcopy: moving loadable section .bss.textdata, is this intentional?

the resulting .bin file is not then useable and the build fails. If I
copy over the objcopy from 10 and run that instead manually then it
succeeds. If use use the version installed from ports it also succeeds.
I dont belive ipxe is using objcopy wrongly from reading the manual.

Have been looking at the svn logs for the objcopy, and the thing which
stands out is the PIE support stuff, but from my reading that has
been reverted ? This puzzles me...
Comment 1 Ed Maste freebsd_committer 2017-01-20 17:43:48 UTC
objcopy in 11 and later comes from ELF Tool Chain instead of GNU binutils.

Would you attach bin/ipxe.pxe.tmp to this PR for further investigation?
Comment 2 pete 2017-01-22 18:26:40 UTC
(In reply to Ed Maste from comment #1)

Slightly too big to attach (7 meg uncompressed) so have uploaded here, xz compressed:


http://www.twisted.org.uk/~pete/ipxe.pxe.tmp.xz
Comment 3 Mitchell Horne 2018-01-09 16:35:53 UTC
(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 Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .prefix           PROGBITS        00000000 000134 000cb1 00 WAX  0   0  1
  [ 2] .text16.early     PROGBITS        00000000 000df0 0000ee 00 WAX  0   0  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  4
  [ 7] .bss.textdata     NOBITS          000c9f00 0cb780 0a5580 00  WA  0   0 128
  [ 8] .zinfo            PROGBITS        00000000 0cb6f8 000080 00   A  0   0  1
  [ 9] .debug_info       PROGBITS        00000000 0cb778 398f31 00      0   0  1
  [10] .debug_abbrev     PROGBITS        00000000 4646a9 054828 00      0   0  1
  [11] .debug_aranges    PROGBITS        00000000 4b8ed1 008e50 00      0   0  1
  [12] .debug_line       PROGBITS        00000000 4c1d21 059425 00      0   0  1
  [13] .debug_str        PROGBITS        00000000 51b146 05a0b9 01  MS  0   0  1
  [14] .debug_frame      PROGBITS        00000000 575200 02ec7c 00      0   0  4
  [15] .debug_loc        PROGBITS        00000000 5a3e7c 15183d 00      0   0  1
  [16] .debug_ranges     PROGBITS        00000000 6f56b9 00ced0 00      0   0  1
  [17] .shstrtab         STRTAB          00000000 702589 0000c5 00      0   0  1
  [18] .symtab           SYMTAB          00000000 702970 01af40 10     19 4079  4
  [19] .strtab           STRTAB          00000000 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
Comment 4 jack 2018-01-23 09:42:30 UTC
MARKED AS SPAM
Comment 5 jack 2018-01-23 09:46:35 UTC
MARKED AS SPAM
Comment 6 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2018-01-24 00:09:03 UTC
The content of attachment 189987 [details] has been deleted for the following reason:

spam