Re: [PATCH] Use offsets instead of addresses in ELF_SECTION_IN_SEGMENT

[Alan Modra <amodra at gmail dot com>]

On Thu, May 24, 2018 at 01:18:08PM +0000, Alan Hayward wrote:
> > On 23 May 2018, at 14:39, Alan Modra <amodra@gmail.com> wrote:
> > I think you may need to detect these armlinker segments.  The problem
> > with disabling the sh_addr comparisons is that sh_offset for
> > SHT_NOBITS sections doesn't really have a physical meaning.  You don't
> > load SHT_NOBITS from file after all.  Your armlinker binaries might
> > have the convention that sh_offset is given values as if a segment's
> > bss part actually existed on disk, but not all ELF binaries will
> > follow that convention.  What's more, the convention breaks down in
> > the presence of multiple tightly packed PT_LOAD segments where any but
> > the last has p_memsz > p_filesz.  That situation would lead to
> > SHT_NOBITS sections having sh_offset values corresponding to the
> > PT_LOAD segment past the one to which they actually belong.
> > 
> > If the armlinker only ever creates one PT_LOAD segment, it might be
> > possible to accommodate it by disabling check_vma whenever there is
> > just one PT_LOAD segment.
> 
> Unfortunately, there is one PT_LOAD section per load region, and the
> number of load regions is arbitrary and defined by the user.
> 
> I’ve been looking at ways to reliably detect if the armlinker was used.
> Sadly, there is nothing in the elf file to reliably detect armlinker arm
> binaries vs gnu linker arm binaries.
> 
> Am I right in thinking that both the zero offsets for SHT_NOBITS and the
> tightly packed binaries are things that could appear in an Arm linux binary?
> (I suspect you could write a linker script to do it). If so, then it wouldn’t
> be safe to do something like "if (Arm and Linux) check_vma=false”.

Current GNU ld follows the ELF gABI which says of sh_offset:

    This member's value gives the byte offset from the beginning of
    the file to the first byte in the section. 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.

GNU ld interprets "conceptual placement" as if the PT_LOAD segment
existed in the file for the entire p_memsz not just its p_filesz.  I'm
farily certain we had times in the past where that wasn't the case,
and of course I can't say much about other linkers, which is why I
made the comment about "not all ELF binaries will follow that
convention".  (You could argue that GNU binutils shouldn't care about
binaries that don't follow this convention, and I think I mostly
agree..)

BTW, this interpretation of conceptual placement can lead to sh_offset
being past the end of file, and overlapping with sh_offset for
following sections if there are multiple PT_LOAD segments.  And yes,
you could generate such binaries for any ELF target using linker
scripts.

-- 
Alan Modra
Australia Development Lab, IBM