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: Some extensions to the .section directive for ELF and COFF

On 28 March 2015 at 08:23, Alan Modra <> wrote:
> On Fri, Mar 27, 2015 at 08:48:32AM -0400, Rafael EspÃndola wrote:
>> The use case in mind is saving size during -ffunction-section,
>> -fdata-section, so we need real sections, not subsections.
> You said you wanted multiple .text sections with the same group
> signature, or at least that's what I understood.  Why?  If they are
> part of the same group then surely a single .text is sufficient.

Not for --gc-sections.

>> Alan, why is section symbols a problem? We just produce multiple
>> sections symbols.
> They may not be any trouble at all, but some targets create a normal
> symbol with the same name as the section (sorry, I wasn't being very
> clear when I said section symbols).  Presumably the symbol is used in
> expressions relative to the start of the section, but I guess if your
> assembly doesn't use that symbol you won't have a problem.

Yes, I think that is a case of "just don't use this feature then". If
the code is currently doing

.long .text.foobar

you can keep doing it and not rename the section or rename it and put
a .Lsomething at the start of it.

>> Would an unique id help with the other issues (not
>> familiar with ARM and IA64).
> I'm also not that familiar, but I know that some ARM directives create
> unwind information, stored in .ARM.exidx and .ARM.extab sections.
> The section names are modified if the directives are in or
> and the sections are made part of the group if the
> directive was in a group .text section.  ie. the assembler knows about
> linkonce and comdat group sections, and names emitted by gcc
> -ffunction-sections.  If you're using some other naming scheme then
> you might need to tweak code in the ARM and IA64 assemblers.

Yes, anything that depends on the section names would be incompatible

A quick update is that we tried enabling the feature when using llvm's
integrated assembler
and found some cases of PPC and ARM codegen jumping back and forth
between sections. It looks
like they can be fixed, but I am afraid there might be a long tail.

I am currently inclined to go with the unique id option. I will
implement it Monday morning to
see what it looks like.


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