This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Auto-generated .rodata contents and __attribute__((section))


On Thu, May 17, 2018 at 11:10 PM Segher Boessenkool <
segher@kernel.crashing.org> wrote:

> On Thu, May 17, 2018 at 06:10:13PM +0200, Michael Matz wrote:
> > On Wed, 16 May 2018, Richard Biener wrote:
> > > > Are constant pool entries merged at compile time or at link time? I
> > > > would presume it should be done at link time because otherwise
you're
> > > > only merging entries within a single compilation unit (which doesn't
> > > > sound that useful in a big project with hundreds of source files),
> > > > right?
> > >
> > > constant pool entries are merged at compile time.  There's no such
thing
> > > as mergeable constant pool sections
> >
> > Actually there is in ELF.  Mergable sections can not only hold strings,
> > but also fixed-size entities (e.g. 4 or 8 byte constants).  Those are
> > merged content-wise at link time and references properly rewritten.  Of
> > course, those still aren't per-function.

Interesting.  Do they allow merging across such sections?  Consider
a 8 byte entity 0x12345678 and 4 byte entities 0x1234 0x5678,
will the 4 byte entities share the rodata with the 8 byte one?  I believe
GCC pulls off such tricks in its internal constant pool merging code.

It might be worth gathering statistics on the size of constant pool
entries for this.

Now the question is of course if BFD contains support for optimizing
those sections.

> It also works correctly in combination with -ffunction-sections,
> -fdata-sections, -Wl,--gc-sections.  And not with per-function constant
> pools like on arm-linux; I'm not sure how that could ever work.


> Segher


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