Re: Patch to the way BFD reads overlaid ELF sections

[Alan Modra <amodra at bigpond dot net dot au>]

On Fri, May 03, 2002 at 02:52:21PM +0100, Richard Sandiford wrote:
> 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?

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

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

Yes.

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

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre