Fwd: [PATCH] x86-64: Align L(SP_RANGE)/L(SP_INF_0) to 8 bytes [BZ #21955]

[H.J. Lu]

On Tue, Aug 15, 2017 at 1:28 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> 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).
>

After a closer look, the bug is

         .section .rodata.cst8,"aM",@progbits,8
...
        .p2align 2  <<<<<< 4 byte aligned.

Here is the new patch.  OK for master?


-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-x86-64-Align-L-SP_RANGE-L-SP_INF_0-to-8-bytes-BZ-219.patch
Type: text/x-patch
Size: 2212 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170815/ad2e12d2/attachment.bin>