Re: [patch] bfd_elf_bfd_from_remote_memory() workaround for the ELF misalignment [Re: loadbase alignment - ld.so/prelink/kernel or bfd_elf_bfd_from_remote_memory() bug?]

[Roland McGrath <roland at redhat dot com>]

> So what we are doing here is guessing from the program headers where
> to find other bits that would have been in the disk file, but are not
> part of the ELF object's memory image.  Then we try to decide whether
> what we have in memory is likely to include them or not.  Is that
> about right?

Exactly so.

> If it is still an issue, IMHO we should fix that instead of attempting
> to recover the section headers.  The corner cases are too cornered.

I agree that gdb should be fixed to do the best possible with no sections.
My tendencies lead me to want the function in question always to do the
best it can on the terms it describes for itself, regardless.  That is
especially attractive given that in the only real-world uses right now, it
can in fact win.

> What I'm missing - I'm sure it's there somewhere - is how you got from
> "can usually see the whole text segment, including [some loaded
> sections]" to "need to know the page size".  .eh_frame will be found
> via the program headers, .dynsym will be indicated by .dynamic, and
> all three are included in both p_filesz and p_memsz.  I don't see why
> we need any heurestics for this case.

No, you're right to miss it because it's not really there.  I just leapt to
"want as much as you can get", and from there the page size is inevitable.
But for all those uses, p_filesz is plenty.  It's just those tendencies of mine.

Honestly, I don't care what BFD does.  
I was just airing everything I could think of on the subject.


Thanks,
Roland