This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Auto-generated .rodata contents and __attribute__((section))
On Tue, May 15, 2018 at 9:56 PM Julius Werner <jwerner@chromium.org> wrote:
> > I think you are asking for per-function constant pool sections. Because
> > we generally cannot avoid the need of a constant pool and dependent
> > on the target that is always global. Note with per-function constant
> > pools you will not benefit from constant pool entry merging across
> > functions. I'm also not aware of any non-target-specific (and thus not
> > implemented on some targets) option to get these.
> Thanks, yeah, that sounds like what I need. Is there any way to get that
> behavior today, even for a specific target? (I'm mostly interested in
> x86_64, armv7 and aarch64.) And are you saying that there are some targets
> for which it would be impossible to provide this behavior? Or just that
> it's not implemented for all targets today?
It's not implemented for all targets and there may be no way to force it
for all constants.
> 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 so the closest thing would be to
emit each entry into its own comdat or linkonce section and have the
general linker script merge them pattern-based into .rodata from
.rodata.HASHVALUEOFACTUALCONSTANT. And then of course you'll
run into hash collisions so I guess it's not a too bright idea but instead
some way of making a mergeable rodata section (which requires
meta data for its entries) would be a solution.
> So if
> they're merged at link time, shouldn't it be possible to do that merging
> after a linker script condensed all the per-function input sections that
> are left after --gc-sections back into a single big .rodata output
section?
> (In my case, the linker script would instead condense all the constant
pool
> sections for marked functions into .special_area.rodata and all the others
> into .rodata, and then it should be merging internally within those two
> output sections.)
> > Does it work better if you make this "static const"?
> Yes, then I can declare an __attribute__((section)) for that specific
> variable. However, that doesn't really seem like a safe and scalable
> approach, especially since it's hard to notice when you missed a variable.
> I'd like to have a way that I can annotate a function and that whole
> function (with everything it needs, except for globals) gets put into a
> special section (or a set of special sections with a common prefix or
> suffix), without having to rewrite the source to accommodate for this
every
> time.