llvm dev - Jun 2015 - [LLVMdev] [lld] How do I prevent .note sections from being eliminated?

On Sat, Jun 13, 2015 at 01:08:50PM +0300, Simon Atanasyan
wrote:
> Hi,
> 
> If you need to control content of output .note section, take a look at
> ARMExidxSection, MipsReginfoSection, MipsOptionsSection classes. If
> you need to copy sections from input to output, use SDataSection (from
> Hexagon) as a reference point.
> 
Hi Simon,

Thanks for the reply.  I have a few more follow up questions.

ELFFile::handleSectionWithNoSymbols() returns false for SHT_NOTE.  This
means that ELFFile::createAtoms() never creates an atom for .note sections.
It seems like even if I use something like SDataSection, then I will still
need to modify ELFFIle::handleSectionWithNoSymbols().  What is the best
way to do this?  Should I make the function virtual and override it in
AMDGPUELFFile.cpp?

In ELFDefinedAtom::doContentType(), SHT_NOTE sections are only assigned
the typeR[OW]Note ContentType if they have the SHF_ALLOC flag.  This is
because any section without SHF_ALLOC is assigned the typeNoAlloc
ContentType before the section type is ever considered.  Is this a bug
or are SHT_NOTE sections required to have the SHF_ALLOC flag?

Thanks,
Tom
> On Sat, Jun 13, 2015 at 6:28 AM, Tom Stellard <tom at stellard.net>
wrote:
> > I'm working on an AMDGPU target for lld, and I'm trying to
link a single
> > .o file with a .note section, but the .note section is missing from
the
> > resulting a.out file.  How can I control which sections get copied
over
> > to the executable?  Is there a target hook to implement?
> 
> Simon

On Mon, Jun 15, 2015 at 6:12 PM, Tom Stellard <tom at stellard.net>
wrote:
> ELFFile::handleSectionWithNoSymbols() returns false for SHT_NOTE.  This
> means that ELFFile::createAtoms() never creates an atom for .note sections.
> It seems like even if I use something like SDataSection, then I will still
> need to modify ELFFIle::handleSectionWithNoSymbols().  What is the best
> way to do this?  Should I make the function virtual and override it in
> AMDGPUELFFile.cpp?
Yes, you can make handleSectionWithNoSymbols() virtual and override it
in ELFFile class descendant.
> In ELFDefinedAtom::doContentType(), SHT_NOTE sections are only assigned
> the typeR[OW]Note ContentType if they have the SHF_ALLOC flag.  This is
> because any section without SHF_ALLOC is assigned the typeNoAlloc
> ContentType before the section type is ever considered.  Is this a bug
> or are SHT_NOTE sections required to have the SHF_ALLOC flag?
It depends on your ABI requirement. If a .note section does not need
to occupy memory during a process execution it should not have
the SHF_ALLOC flag.

-- 
Simon Atanasyan

On Tue, Jun 16, 2015 at 12:05:39PM +0300, Simon Atanasyan
wrote:
> On Mon, Jun 15, 2015 at 6:12 PM, Tom Stellard <tom at stellard.net>
wrote:
> > ELFFile::handleSectionWithNoSymbols() returns false for SHT_NOTE. 
This
> > means that ELFFile::createAtoms() never creates an atom for .note
sections.
> > It seems like even if I use something like SDataSection, then I will
still
> > need to modify ELFFIle::handleSectionWithNoSymbols().  What is the
best
> > way to do this?  Should I make the function virtual and override it in
> > AMDGPUELFFile.cpp?
> 
> Yes, you can make handleSectionWithNoSymbols() virtual and override it
> in ELFFile class descendant.
> 
> > In ELFDefinedAtom::doContentType(), SHT_NOTE sections are only
assigned
> > the typeR[OW]Note ContentType if they have the SHF_ALLOC flag.  This
is
> > because any section without SHF_ALLOC is assigned the typeNoAlloc
> > ContentType before the section type is ever considered.  Is this a bug
> > or are SHT_NOTE sections required to have the SHF_ALLOC flag?
> 
> It depends on your ABI requirement. If a .note section does not need
> to occupy memory during a process execution it should not have
> the SHF_ALLOC flag.
> 
What I want to do is emit a .note section *without* SHF_ALLOC.  However,
the current implementation won't let me do this, because it assigns the
section a content type of typeNoAlloc, rather than typeR[OW]Note.
I'm just wondering the best way to fix this.

-Tom
> -- 
> Simon Atanasyan