Re: cpp /usr/include/threads.h fails; modfl segfaults

[Ken Brown <kbrown@cornell.edu>]

On 8/29/2020 8:52 AM, airplanemath via Cygwin wrote:
> Hello,
> 
> I have two reports.  A brief description of the system:
> $ uname -a | sed "s/${HOSTNAME}/\${HOSTNAME}/g"
> CYGWIN_NT-10.0 ${HOSTNAME} 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin

In the future, please use two separate emails for two unrelated bug reports.

> The first report:
> 
> $ cpp /usr/include/threads.h
> # 1 "/usr/include/threads.h"
> # 1 "<built-in>"
> # 1 "<command-line>"
> # 1 "/usr/include/threads.h"
> /usr/include/threads.h:30:10: fatal error: machine/_threads.h: No such
> file or directory
>     30 | #include <machine/_threads.h>
>        |          ^~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> 
> $ cygcheck -p machine/_threads.h
> Found 0 matches for machine/_threads.h

It looks like /usr/include/threads.h is a Newlib header that's intended for 
RTEMS.  Here's the commit where it was introduced:

commit c98d01ee0cbc6eb7bbca8f2cde4a46b90ded3784
Author: Jeff Johnston <jjohnstn@redhat.com>
Date:   Tue Oct 13 17:52:34 2015 -0400

     Import <threads.h> from latest FreeBSD.

     - Move types and defines to
       <machine/_threads.h> so that it can be customized per target.

             * libc/include/threads.h: New.
             * libc/sys/rtems/include/machine/_threads.h: Likewise.

There's no machine/_threads.h in the repository for any platform other than 
RTEMS.  My guess is that it shouldn't be included in the Cygwin distro.

> The second report:
> 
> $ cat test.c
> #include <math.h>
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(int argc, char *argv[]) {
>    long double a, b, c;
>    char *num_end = NULL;
>    a = b = c = 0.0L;
>    if (argc != 2) {
>      fprintf(stderr, "Usage: %s NUMBER\n", argv[0]);
>      exit(1);
>    }
>    a = strtold(argv[1], &num_end);
>    b = modfl(a, &c);
>    printf("%Lf %Lf %Lf\n", a, b, c);
>    return 0;
> }
> 
> $ gcc -Og -ggdb -g3 -Wall -Wextra -std=c99 -pedantic test.c -o test.exe
> 
> $ ./test.exe 123.456
> Segmentation fault (core dumped)
> 
> $ gdb --args ./test.exe 123.456
> GNU gdb (GDB) (Cygwin 8.3.1-1) 8.3.1
> ...
> Reading symbols from ./test.exe...
> (gdb) break modfl
> (gdb) run
> Starting program: /home/Daniel/test.exe 123.456
> [New Thread 13960.0x3cf4]
> [New Thread 13960.0xbdc]
> [New Thread 13960.0x4028]
> [New Thread 13960.0x3224]
> [New Thread 13960.0x3810]
> [New Thread 13960.0x1ae4]
> [New Thread 13960.0x3714]
> [Thread 13960.0x4028 exited with code 3697672192]
> [Thread 13960.0x3714 exited with code 0]
> 
> Thread 1 "test" hit Breakpoint 1, modfl (value=<optimized out>,
> iptr=iptr@entry=0xffffcbd0) at
> /usr/src/debug/cygwin-3.1.7-1/winsup/cygwin/math/modfl.c:16
> 16        asm ("subq $8, %%rsp\n"
> (gdb) step
> 38        if (iptr)
> (gdb) step
> 39          *iptr = int_part;
> (gdb) step
> 40        return (isinf (value) ?  0.0L : value - int_part);
> (gdb) step
>        0 [main] test 28439 cygwin_exception::open_stackdumpfile: Dumping
> stack trace to test.exe.stackdump
> [Thread 13960.0x3b5c exited with code 35584]
> [Thread 13960.0x1ae4 exited with code 35584]
> [Thread 13960.0x3810 exited with code 35584]
> [Thread 13960.0xbdc exited with code 35584]
> [Thread 13960.0x3cf4 exited with code 35584]
> [Inferior 1 (process 13960) exited with code 0105400]
> (gdb)
> 
> isinf and isinfl both work just fine, so I'm not sure what's going on there.

I built a version of cygwin1.dll without optimization in the hopes of making 
debugging easier, but the problem doesn't occur with that DLL.  So this is 
somehow tied up with optimization.  BTW, isinf is a macro that expands to 
__builtin_isinf_sign, again suggesting that optimization is involved.

That's as far as I can take it.

Ken