Re: VMA section overlap warnings for overlays

["H.J. Lu" <hjl.tools@gmail.com>]

On Sun, Aug 29, 2010 at 8:20 PM, Alan Modra <amodra@gmail.com> wrote:
> On Sat, Aug 28, 2010 at 06:39:36AM -0700, H.J. Lu wrote:
>> On Sat, Aug 28, 2010 at 6:28 AM, Alan Modra <amodra@gmail.com> wrote:
>> > The real bug was that copy_elf_program_header calculated header_size
>> > from the first section found to be in the segment rather than the
>> > section with the lowest lma.  So a one line fix.  The rest of this
>> > patch is to cope with (and fix) invalid program header p_paddr values.
>>
>> There is no such a thing as "invalid program header p_paddr values"
>> since ELF spec says it has unspecified contents.
>
> Yes, that's technically true.  My language wasn't precise.  I should
> have said inconsistent p_paddr values.
>
>> You can't depend on contents in p_addr in objcopy.
>
> Are you saying that objcopy should throw away all p_paddr values?
> That doesn't make sense at all.  Just because the ELF spec doesn't
> specify p_paddr, doesn't mean that GNU binutils cannot use p_paddr.
> We use p_paddr to record section LMAs, since ELF section headers only
> have a field for VMAs.
>
>> > I won't commit this immediately as I'd like to run some more tests.
>> >
>> >        PR binutils/11953
>> >        * elf.c (copy_elf_program_header): Calculate map->header_size
>> >        from lowest_section, not first_section.  Validate program
>> >        header p_paddr against section lma.  Find lowest_section in
>> >        second loop over headers.
>> >
>>
>> Can we not look at p_addr here?
>
> I don't know what you mean by that question.
>

Can we compute p_addr from other fields and don't check if
it matches the original value?


-- 
H.J.