[patch] bfd/elf.c: fix section overlap warning again

[DJ Delorie]

> s/segment/section/  "segment" is what the program header describes.

isn't P an "Elf_Internal_Phdr *" at that point?

> > +	      /* The first comparison checks for the usual case.  The
> > +		 second checks for segments which overflow the address
> > +		 space.  */
> > +	      if (sec->lma < p->p_paddr + p->p_memsz
> > +		  || (p_end < p->p_paddr && p->p_paddr < sec->lma))
> 
> Isn't it an overflow if p->p_addr == sec->lma in the second case?
> I'd write
> 
> 	      if (sec->lma < p_end
> 		  || (p_end < p->p_paddr && sec->lma >= p->p_paddr))

If "p" is the previous segment/section/whatever, then normally p->lma
is less than sec->lma, because the new section starts after the old
one.  One would hope, at least, else this whole chunk of logic is
wrong.

The normal case is like this:

p->lma ... p->end ... sec->lma ... sec->end

The normal overlap case is like this:

p->lma      ...      p->end
         sec->lma      ...      sec->end

(i.e. the new section has an AT that isn't far enough past the end of
P)

If P overflows, you have this instead:

p->end . . . . . . p->lma
                           sec->lma ... sec->end

So yeah, the == case should be included.  I hope nobody intentionally
*starts* two sections at the same address!

> Hmm, on thinking some more, it's an overflow if
>   sec->lma + sec->size > p->p_addr

Only if P overflows, but you'd then have to also test for sec
overflowing, and in the case I had, sec ended right at the border, so
sec+size was 0x1_0000_0000, and pretty much guaranteed to always be
that way (it's the reset vector's section)

The code in question doesn't test for the case where sec->lma < p->lma
anyway, or the general O(n^2) overlap problem, just the normal "s
follows p" overlap case.

Also, I don't like mixing < and > in the same inequality checks.  I
get confused enough without putting lesser and greater quantities on
random sides of the comparison.  I try to always use < or <= for
comparing addresses, so that the operands are in the right "order"
memory-wise.