Patch to the way BFD reads overlaid ELF sections
Richard Sandiford
rsandifo@redhat.com
Thu May 2 08:14:00 GMT 2002
Alan Modra <amodra@bigpond.net.au> writes:
> On Wed, May 01, 2002 at 07:27:15PM +0100, Richard Sandiford wrote:
> > * elf.c (_bfd_elf_make_section_from_shdr): Base the LMA on the
> > smallest matching segment.
>
> OK, but please put a comment in the code describing why we ought to
> look through all the segments.
On second thoughts, if I can't get it right for like-sized overlays
too, it's probably best to leave things be.
If .bss1 and .bss2 are the same size in:
OVERLAY
{
.bss1 { ... }
.bss2 { ... }
}
then we end up with two segments that have the same file offset,
file size (0), VMA, and memory size. Is it reasonable to expect
BFD to get the mapping right in this case?
The only way I can think of making it work is to have the
file offsets for zeroed sections and segments point to the
segment structure itself. Would that go against the ELF spec?
I notice (for the section case) it says:
One section type, SHT_NOBITS described below, occupies no
space in the file, and its sh_offset member locates the
conceptual placement in the file
but I don't really understand what "conceptual placement" is,
or how it affects things.
If we made this change, the segments for the overlay-size test
would look like:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
[...]
LOAD 0x000074 0x00020000 0x00020000 0x00000 0x00010 RW 0x1000
LOAD 0x000094 0x00020000 0x00020010 0x00000 0x00030 RW 0x1000
LOAD 0x0000b4 0x00020000 0x00020040 0x00000 0x00020 RW 0x1000
LOAD 0x0000d4 0x00020030 0x00020060 0x00000 0x00230 RW 0x1000
LOAD 0x003000 0x00010000 0x00030000 0x000a0 0x000a0 R E 0x1000
LOAD 0x004020 0x00010020 0x000300a0 0x00040 0x00040 R E 0x1000
LOAD 0x005020 0x00010020 0x000300e0 0x00020 0x00020 R E 0x1000
LOAD 0x005260 0x00020260 0x00030100 0x00030 0x00030 RW 0x1000
LOAD 0x006260 0x00020260 0x00030130 0x00040 0x00040 RW 0x1000
LOAD 0x007260 0x00020260 0x00030170 0x00050 0x00050 RW 0x1000
where the offsets for the first four point to the segments themselves.
The section table would be:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .bss1 NOBITS 00020000 000074 000010 00 WA 0 0 1
[ 2] .bss2 NOBITS 00020000 000094 000030 00 WA 0 0 1
[ 3] .bss3 NOBITS 00020000 0000b4 000020 00 WA 0 0 1
[ 4] .mtext PROGBITS 00010000 003000 000020 00 AX 0 0 1
[ 5] .mbss NOBITS 00020030 0000d4 000230 00 WA 0 0 1
[ 6] .text1 PROGBITS 00010020 003020 000080 00 AX 0 0 1
[ 7] .text2 PROGBITS 00010020 004020 000040 00 AX 0 0 1
[ 8] .text3 PROGBITS 00010020 005020 000020 00 AX 0 0 1
[ 9] .data1 PROGBITS 00020260 005260 000030 00 WA 0 0 1
[10] .data2 PROGBITS 00020260 006260 000040 00 WA 0 0 1
[11] .data3 PROGBITS 00020260 007260 000050 00 WA 0 0 1
[...]
and the current mapping code will hande it fine.
Although, while I'm here, there seems to be some dead code in
_bfd_elf_make_section_from_shdr():
if (phdr->p_type == PT_LOAD
&& (bfd_vma) hdr->sh_offset >= phdr->p_offset
&& (hdr->sh_offset + hdr->sh_size
<= phdr->p_offset + phdr->p_memsz)
&& ((flags & SEC_LOAD) == 0
|| (hdr->sh_offset + hdr->sh_size
<= phdr->p_offset + phdr->p_filesz)))
{
...
}
Checking
hdr->sh_offset + hdr->sh_size against both
phdr->p_offset + phdr->p_memsz and
phdr->p_offset + phdr->p_filesz
seems to be redundant, since p_memsz can't be smaller than p_filesz.
OK to rework as follows? Just a clean-up (I hope).
Both patches checked on i686-pc-linux-gnu, mips-elf, mipsel-elf,
mips64-elf, arm-coff, arm-elf and powerpc-eabi.
Richard
[bfd/]
* elf.c (assign_file_positions_for_segments): If a loadable segment
has no file contents, set its offset to the position of the segment
header itself.
[bfd/]
* elf.c (_bfd_elf_make_section_from_shdr): Simplify check for
file contents. Update comment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: overlay-phdr-offset.diff
Type: text/x-patch
Size: 1246 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20020502/7399ea10/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elf-phdr-mapping.diff
Type: text/x-patch
Size: 2708 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20020502/7399ea10/attachment-0001.bin>
More information about the Binutils
mailing list