This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] x86-64: Put L(SP_INF_0) in .rodata.cst4 section [BZ #21955]
On Tue, 15 Aug 2017, H.J. Lu wrote:
> On Tue, Aug 15, 2017 at 1:02 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> > On Tue, 15 Aug 2017, H.J. Lu wrote:
> >
> >> > [BZ #21955]
> >> > * sysdeps/x86_64/fpu/e_expf.S (L(SP_INF_0)): Place it in
> >> > .rodata.cst4 section.
> >>
> >> L(SP_RANGE) has the same issue. This updated patch fixes both.
> >
> > It's a lot more than just expf. There are various other x86_64 and x86
> > libm files that could use .rodata.cstN but don't. (Obviously this only
> > works for invididual objects where the code doesn't use offsets from one
> > object to another, not when an array of two or more objects is being used
> > unless you choose the section appropriately to preserve the array as
> > such.)
>
> Aren't .rodata.cstN optimization? In case of e_expf.S, it is a correctness
> issue.
They are generally optimization.
Could you explain this correctness issue in more detail? SP_INF_0 appears
to be an array of two 4-byte values. Because it's used as an array, the
two values need to stay adjacent. That is, I'd expect it to need, for
correctness, to be in .rodata.cst8, as it is at present, and *not*
.rodata.cst4 (if in .rodata.cst4, it might get split up as those values
get unified with other values in that section).
--
Joseph S. Myers
joseph@codesourcery.com