Build Failure on Cygwin

Joel Sherrill joel@rtems.org
Tue Oct 20 19:18:52 GMT 2020


On Tue, Oct 20, 2020 at 1:23 PM Hannes Domani <ssbssa@yahoo.de> wrote:

>  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


It's like dejavu all over again. :(

I moved the ticket from gdb to binutils and added the text above.

Hopefully, since it is now aimed in the right direction, it might get
attention.

Thanks.

--joel

>
>
>
> Hannes
>


More information about the Gdb mailing list