Re: Patch to the way BFD reads overlaid ELF sections

[Richard Sandiford <rsandifo at redhat dot com>]

Alan Modra <amodra@bigpond.net.au> writes:
> > 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.
> 
> Well, if they _did_ occupy space, that's where they would be in the
> file.

But, but... what does that mean?  If they did occupy space, everything
after them would have different offsets.  Oh well.

> > 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.
> 
> Err, since p_filesz must be smaller, it's the more restrictive
> limit, no?

Right.  I meant that the first check was redundant if you then did the
second.  So the patch replaced it with a single end-of-range check,
where the size of the range depends on the kind of section.

In the patch, I used 0 as the file size of NOBITS sections.  I think
using 'p_memsz' instead would exactly preserve the existing behaviour,
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.

So after the patch, we execute the if statement for all BSS sections
with a matching offset, and leave the code at the end of the if-statement
to select between them based on VMA range.

But if you think it's wrong, or don't think it's any cleaner,
just say so.

Richard