[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10

[bugzilla-noreply]

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"

[Bug 216316] objcopy (elfcopy) in 11 appears to have a regression compared to the version in 10

[bugzilla-noreply]

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

[bugzilla-noreply]

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

[bugzilla-noreply]

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

[bugzilla-noreply]

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

[bugzilla-noreply]

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

[bugzilla-noreply]

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

[bugzilla-noreply]

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

[bugzilla-noreply]

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=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

[bugzilla-noreply]

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

[bugzilla-noreply]

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

[bugzilla-noreply]

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"