This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: [PATCH] x86-64: Put L(SP_INF_0) in .rodata.cst4 section [BZ #21955]


On Tue, Aug 15, 2017 at 4:14 PM, H.J. Lu <hjl.tools@gmail.com> 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.

Please elaborate - I was just about to ask whether this actually makes
any difference to anything, other than abstract tidiness of the
.rodata segment.  The code actually misbehaves without this change?
How?

zw


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