This is the mail archive of the binutils@sourceware.org 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: portable method to add a new output section?


On 02/01/08 10:58:02, H.J. Lu wrote:
> On Fri, Feb 01, 2008 at 10:10:42AM -0800, Gary Funck wrote:
> > 
> > This isn't an issue for me, but I was curious as to why
> > the initialzed data doesn't make it into the section.
> 
> Please follow
> 
> http://sourceware.org/ml/binutils/2008-01/msg00068.html

Thanks, this note summarizes the dilemma:
http://sourceware.org/ml/binutils/2008-01/msg00080.html

FYI, the section in question is initially
declared with the following attributes:
  .section        upc_shared,"aw",@progbits
Which according to the assembler manual, says the section
is allocatable, writeable, and that it contains data.
(Note: we are in the process of changing this, probably
to "a",@nobits so the current ld behavior of not outputting
the section works for us.  However, I did find it surprising.)

Perhaps whether the section attributes are @progbits or
@nobits should determine whether data is actually written
into the executable? With some potential ld script over-ride
perhaps?

Question: what does it mean when a section is marked
as ollocatable?  I notice that the DWARF sections are
are displayed by objdump as "CONTENTS, READONLY, DEBUGGING".
but not ALLOC.  Does this mean that the DWARF sections
(and their data) appear in the executable, but that the
data will not be loaded into the load image when the
program is run?  Perhaps that's the best method for
ensuring the data makes it into the executable, and
then NOLOAD speicifies that no data is written into the
executable?


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