This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PATCH: segfault in bfd with large static binary
On Fri, Feb 03, 2006 at 05:45:09PM +0000, Nick Clifton wrote:
> Hi H. J.
>
> >p_paddr
> > On systems for which physical addressing is relevant, this member
> > is reserved for the segment's physical address. Because System V
> > ignores physical addressing for application programs, this member
> > has unspecified contents for executable files and shared objects.
> >
> >We should never check it for System V based systems.
>
> Ok - so presumably what we need is another elf backend flag to tell us
> whether or not we should pay attention to the p_paddr field, yes ? Then
> we have to make sure that we set this flag correctly for all the
> different ELF targets we currently support and then modify the current
> code to ignore p_paddr when it is not supported. Right ?
It sounds good. But Linux uses elf_x86_64 and elf_i386. Some elf_x86_64
or elf_i386 targets may want p_paddr.
We can put anything reasonable in p_paddr. But we can't assume that
it means anything when we read it.
If you take a look at process_program_headers in readelf.c, it doesn't
use p_paddr at all when it maps sections to segments.
I think we can rename copy_private_bfd_data in elf.c to something
like rewrite_elf_program_header and add a new function,
copy_elf_program_header. Then copy_private_bfd_data can be
if any section covered by ELF program header is changed then
call rewrite_elf_program_header
else
call copy_elf_program_header
I really don't mind if rewrite_elf_program_header doesn't work
correctly in all cases. But copy_elf_program_header should work
correctly in all cases.
H.J.