This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [lto]: PATCH: New section names.
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, Mark Mitchell <mark at codesourcery dot com>
- Date: Mon, 11 Sep 2006 09:58:36 +0100
- Subject: Re: [lto]: PATCH: New section names.
- References: <4501B39C.9010807@naturalbridge.com>
On Fri, 2006-09-08 at 19:17, Kenneth Zadeck wrote:
> As mark suggested:
>
> > > One piece of the api that has slipped through the cracks is what am I to
> > > name the sections that the output is in.
>
> > I suggest ".lto_$name", where $name is the function's
> DECL_ASSEMBLER_NAME. We > should also select an ELF section type number
> from the reserved portion of the number > space, but that's a detail we
> can postpone.
Hmm, I think the name ought to be something like .gnu.lto_$name. The
elf spec has the following to say on this subject:
Section names with a dot (.) prefix are reserved for the system,
although applications may use these sections if their existing
meanings are satisfactory. Applications may use names without
the prefix to avoid conflicts with system sections. The object
file format lets one define sections not shown in the previous
list. An object file may have more than one section with the
same name.
Section names reserved for a processor architecture are formed
by placing an abbreviation of the architecture name ahead of the
section name. The name should be taken from the architecture
names used for e_machine. For instance .FOO.psect is the psect
section defined by the FOO architecture. Existing extensions are
called by their historical names.
while GNU isn't a processor architecture, using that does fit in with
the philosophy expressed here.
Also, there are no parts of the section type number space that are
reserved to the toolchain vendor; there are parts for the architecture,
parts for the OS, and parts for the user in the section type field, but
sadly none for the compiler.
R.