Build Failure on Cygwin

[Hannes Domani]

 Am Dienstag, 20. Oktober 2020, 15:35:52 MESZ hat Joel Sherrill <joel@rtems.org> Folgendes geschrieben:

> On Tue, Oct 20, 2020 at 6:39 AM Christian Biesinger <cbiesinger@google.com> wrote:
> > On Mon, Oct 19, 2020 at 9:34 PM Joel Sherrill <joel@rtems.org> wrote:
> >> And to this from Christian.
> >>
> >> > I've seen this error on various toolchains. I believe it to be a gcc
> >> > bug; however, since it still seems to be an issue on some platforms,
> >> > maybe gdb should avoid using global (nonstatic) threadlocal
> >> > variables... (and instead abstract access to this variable through
> >> > getters/setters)
> >>
> >> I emailed Corrina from Cygwin and she thought it was a gdb issue
> >> and not a Cygwin issue. I didn't know which project was best to file
> >> this on.
> >
> > Did she have any more thoughts on that? Like, what should gdb do differentl
>
> Only this:
>
> "That's GDB only, I think.  thread_local_segv_handler is not defined,
> but that's something in GDB which is not created when building on
> Cygwin, erroneously."
>
> I've updated my cygwin this week and GCC is 10.2.0 and the
> packaged gdb is 8.3.1.
>
> I added V=1 and event-top.o is definitely being linked in. Trying
> nm on it, I see this:
>
> $ nm event-top.o  | grep -i segv
> 0000000000000000 D __emutls_v.thread_local_segv_handler
> 0000000000000640 t _ZL14handle_sigsegvi
>
> $ nm event-top.o  | c++filt | grep -i segv
> 0000000000000000 D __emutls_v.thread_local_segv_handler
> 0000000000000640 t handle_sigsegv(int)
>
> This is the first time I've looked at thread local storage in a symbol
> table. We haven't had issues with it like this compiling for RTEMS.
>
> Any ideas for something else to poke at?

In the previous thread Jim Wilson said this is a binutils bug, and he fixed
a similar bug already for RISC-V:
https://sourceware.org/pipermail/gdb/2020-March/048449.html
https://sourceware.org/bugzilla/show_bug.cgi?id=23244


Hannes