From: Hannes Domani <ssbssa@yahoo.de>
To: Christian Biesinger <cbiesinger@google.com>,
Joel Sherrill <joel@rtems.org>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Build Failure on Cygwin
Date: Tue, 20 Oct 2020 18:23:39 +0000 (UTC) [thread overview]
Message-ID: <2088332346.2505262.1603218219278@mail.yahoo.com> (raw)
In-Reply-To: <CAF9ehCXQgvHOExLNCv5By3v4iBUknV6RxjdaU5mc9P7kGiXr9g@mail.gmail.com>
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
next prev parent reply other threads:[~2020-10-20 18:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 17:26 Joel Sherrill
2020-10-19 17:42 ` Christian Biesinger
2020-10-19 17:46 ` Hannes Domani
2020-10-19 19:33 ` Joel Sherrill
2020-10-19 23:03 ` Joel Sherrill
2020-10-20 11:39 ` Christian Biesinger
2020-10-20 13:35 ` Joel Sherrill
2020-10-20 18:23 ` Hannes Domani [this message]
2020-10-20 19:18 ` Joel Sherrill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2088332346.2505262.1603218219278@mail.yahoo.com \
--to=ssbssa@yahoo.de \
--cc=cbiesinger@google.com \
--cc=gdb@sourceware.org \
--cc=joel@rtems.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).