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

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216316

--- Comment #9 from Michael Brown <mcb30 at ipxe.org> ---
(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       0000090d  00000000  00000000  00000154  2**0
                  CONTENTS, ALLOC, LOAD, CODE
...
  7 .textdata     000ce040  00000000  00001370  000014c0  2**5
                  CONTENTS, ALLOC, LOAD, CODE

which correctly shows that we have (at least) two sections with a VMA of
00000000, but that .prefix should appear at offset 00000000 and .textdata at
offset 00001370 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.