This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Problem with arm-elf -> arm-a.out objcopy
Jason R Thorpe <thorpej@wasabisystems.com> writes:
> The problem, however (and I'm pretty sure this has been brought up
> before), is that the BFD ELF backend simply refuses to create anything
> NMAGIC-like. I think the following snippet of code, from elf.c
> assign_file_positions_for_segments(), is at fault:
>
> if ((abfd->flags & D_PAGED) != 0)
> off += (m->sections[0]->vma - off) % bed->maxpagesize;
> else
> {
> bfd_size_type align;
>
> align = 0;
> for (i = 0, secpp = m->sections; i < m->count; i++, secpp++)
> {
> bfd_size_type secalign;
>
> secalign = bfd_get_section_alignment (abfd, *secpp);
> if (secalign > align)
> align = secalign;
> }
>
> off += (m->sections[0]->vma - off) % (1 << align);
> }
>
> Now, as far as I can tell, what's happening here is that:
>
> if demand-paged, align the file offset to the max page size.
> Otherwise, find the maximum program section alignment and
> align the file offset to that.
I think, to be precise, that code snippet says that if the output file
is not demand paged, the segment should be aligned to maximum
alignment of the sections contained within that segment. That seems
reasonable.
What do you see in the linker map file? That should tell you where
the large alignment is coming from. I don't see where it is coming
from based on what you wrote.
> Maybe the right question to ask is -- "Where does that 2**15
> alignment come from?" I'll note that "ld -N" seems to do
> the right thing with the file offset:
You want to use ld -N anyhow if you are creating an NMAGIC file, don't
you?
Ian