Re: [PATCH/QUESTION] newlib: fenv: AArch64 Cygwin linking fixes

On 24/06/2025 09:27, Corinna Vinschen wrote:
> On Jun 23 16:36, Richard Earnshaw (lists) wrote:
>> On 16/06/2025 12:31, Radek Barton wrote:
>>> Hello.
>>>
>>> This is more a question than patch submission: Without the attached changes, the Cygwin cannot be linked for AArch64 failing on:
>>> ```
>>> ld: cannot export _fe_nomask_env: symbol not defined
>>> ld: cannot export fedisableexcept: symbol not defined
>>> ld: cannot export fegetexcept: symbol not defined
>>> ld: cannot export fegetprec: symbol not defined
>>> ld: cannot export fesetprec: symbol not defined
>>> ```
>>> Can anybody share some insights why are those changes needed and whether there is a better way how to overcome this issue?
>>>
>>> Note that the `feenableexcept`, `fedisableexcept`, `fegetexcept` implementations are similarly defined in `newlib/libc/machine/mips/machine/fenv-fp.h` for MIPS architecture as well.
>>>
>>> Thank you,
>>>
>>> Radek
>>>
>>
>> Ugh, this is a real rat's nest of code...
>>
>> I may be on completely the wrong track, but I think the clue is in the comment:
>>
>>   +/* We currently provide no external definitions of the functions below. */
>>
>> So it is expected that these functions have no definition in a file, but will be inlined into the calling code when needed.  This is why they are provided in fenv.h.  fenv-fp.h seems to be the internal header that is used for code that will create the non-inlined versions; the header file fenv-fp.h isn't exported from the library though (it's only used while building it), so anything defined there will never be inlined into user code.
>>
>> I suspect that the underlying issue is that coff libraries rely on
>> explicitly exporting symbols, while ELF libraries do that implicitly
>> (unless something is explicitly marked hidden).
> 
> I wonder if this is really the issue, because binutils ld performs
> its auto-export magic for coff symbols for ages on Cygwin.  Unless
> you define exactly the symbols to export in a .def file, that is.
> 
> However, Cygwin's .def file explicitly exports the above fe* symbols.
> 
> They are just not actually present in the object files in case of the
> aarch64 build per Radek.
> 
> 
>> What I don't fully understand is what role __BSD_VISIBLE might have
>> here.  If that's not defined (which I'd think is possible in CYGWIN),
> 
> Only for applications built under Cygwin, but not for building the Cygwin
> DLL itself, which is the problem here.
> 
>> then I can't see how your changes would resolve this.
>>
>> I'm guessing (somewhat) that libm/.../fenv.c should perhaps define __BSD_VISIBLE before including fenv.h to force the inline functions to become visible.
>>
>> The other alternative might be to remove the list of functions scoped by the ifdef from libm/machine/aarch64/fenv.c so that the functions that file exports matches the comment I mentioned above.
>>
>> Perhaps you could try this patch instead of yours and let me know if it resolves the issue:
>>
>> diff --git a/newlib/libm/machine/aarch64/fenv.c b/newlib/libm/machine/aarch64/fenv.c
>> index 3ffe23441..fb6a67dcc 100644
>> --- a/newlib/libm/machine/aarch64/fenv.c
>> +++ b/newlib/libm/machine/aarch64/fenv.c
>> @@ -27,6 +27,9 @@
>>    * $FreeBSD$
>>    */
>>   
>> +/* Enable all fenv-related functions.  */
>> +#define __BSD_VISIBLE
>> +
>>   #define        __fenv_static
>>   #include <fenv.h>
>>   #include <machine/fenv-fp.h>
> 
> Worth a try.
> 
> 
> Thanks,
> Corinna
> 

There's another possibility for what is going wrong here: that on cygwin 
we're somehow picking up the wrong implementation of sys/fenv.h.  For 
example there's a version in libc/include/sys that lacks the inline 
versions of functions that libc/machine/aarch64/sys provides.  If that 
is the case, it might simply be that cygwin is not being configured 
correctly to find the aarch64-specific headers.

I think it would be instructive to look at the pre-processed source of 
fenv.c to see exactly which headers are being used.

R.