This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Patch to the way BFD reads overlaid ELF sections
Alan Modra <amodra@bigpond.net.au> writes:
> > > Well, if they _did_ occupy space, that's where they would be in the
> > > file.
> >
> > But, but... what does that mean?
>
> Hmm, I take it to mean that you can use sh_offset to determine which
> segment the section belongs to. For instance, with .data and .bss
> occupying one segment, .bss would have sh_offset at the end of .data
OK, I can see it makes sense when a section belongs to a segment with
non-zero file size. I'm just not sure what it means when the segment
file size is zero.
> > but it seems odd to attach a meaning to 'phdr->p_offset + phdr->p_memsz'
> > when the bits beyond 'phdr->p_filesz' could be anything.
>
> That's where the conceptual placement comes into play. To take the
> .bss example, sh_offset to sh_offset + sh_size must be within
> p_offset to p_offset + p_memsz.
The case I'm worried about is the one you mention above, when a
segment has some data followed by a zeroed area:
segments
offset filesz memsz
0 0x1000 0x100 0x500 .data1 .bss1
1 0x1100 0x100 0x100 .data2
2 0x1200 0x000 0x100 .bss2
3 0x1200 0x000 0x100 .bss3
sections
offset size
.data1 0x1000 0x100
.bss1 0x1100 0x400
.data2 0x1100 0x100
.bss2 0x1200 0x100
.bss3 0x1200 0x100
the existing 'phdr->p_offset + phdr->p_memsz' check will match
.bss2 and .bss3 to segment 0, even though it should be obvious
from offsets alone that they don't belong there. (In the end,
we pick the right segment, because of your VMA check.)
After the patch we'd only consider segments 2 and 3 to match
offset-wise. We still need the VMA check to distinguish
between them.
Richard