This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH/RFA] Fix C-referenceable sections with explicit LMAs

Nick Clifton <> writes:

> Hi Jason, Hi Alan,
> >  > Orphans are not "merged into the sections".  They have separate output
> >  > sections.  This part of your patch is just plain wrong, and will
> >  > likely break SIZEOF for other people.  I've shown you the way to
> >  > correct your linker scripts to do what you want, yet you persist in
> >  > trying to change the meaning of SIZEOF.  Why?
> > 
> > I don't see how it could actually break SIZEOF for other people (it's
> > very clear that I am the first person to actually try to use both of
> > these linker features at the same time), because there is *no other way*
> > to represent those orphan sections and still have the __start_SECNAME/
> > __stop_SECNAME or the "create arbitrary numbers of these sections and not
> > have to update the linker script" feature work properly.  Because
> > if this, the orphans, when they are sorted with another, representable
> > section, *effectively do change the size of that section*.
> Maybe what we need here is a new keyword then.  Something like
> SIZEOF_INCLUDING_ORPHANS (or something less wordy) which would mean
> "the size of the section plus the size of any attached orphan
> sections".  Then in the documentation we could make it clear that
> SIZEOF is just the size of the basic section without any attachments,
> and provide an example of the difference.

Jason, have you tried using memory regions for this?  Offhand it seems
to me that they could handle this straightforwardly, provided the
orphan placement code copied the memory region of the preceding output
section when creating a new output section.

Otherwise, I guess I agree with Nick that we need a variant of SIZEOF
which includes the size of trailing output sections created to hold
orphans.  It doesn't seem ideal, but I don't see any other
straightforward way to handle the problem with the current linker
script language.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]