* Build Failure on Cygwin @ 2020-10-19 17:26 Joel Sherrill 2020-10-19 17:42 ` Christian Biesinger 2020-10-19 17:46 ` Hannes Domani 0 siblings, 2 replies; 9+ messages in thread From: Joel Sherrill @ 2020-10-19 17:26 UTC (permalink / raw) To: gdb Hi I am getting a build failure on Cygwin /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x5502): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for thread_local_segv_handler' /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x551b): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for thread_local_segv_handler' collect2: error: ld returned 1 exit status This is a build targeting RTEMS based on a tarball fetched from git:(sourceware-mirror-binutils-gdb-8a6e98c). It should correspond to this recent commit: ommit 8a6e98c4a3049d7fb8ffc24b231e8cf3577fd90a Author: GDB Administrator <gdbadmin@sourceware.org> Date: Mon Oct 12 00:00:07 2020 +0000 Automatic date update in version.in Any suggestions on how to fix this? --joel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Build Failure on Cygwin 2020-10-19 17:26 Build Failure on Cygwin Joel Sherrill @ 2020-10-19 17:42 ` Christian Biesinger 2020-10-19 17:46 ` Hannes Domani 1 sibling, 0 replies; 9+ messages in thread From: Christian Biesinger @ 2020-10-19 17:42 UTC (permalink / raw) To: joel, Tom Tromey; +Cc: Reuben Thomas via Gdb On Mon, Oct 19, 2020 at 7:26 PM Joel Sherrill <joel@rtems.org> wrote: > I am getting a build failure on Cygwin > > /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x5502): > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS > init function for thread_local_segv_handler' > /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x551b): > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS > init function for thread_local_segv_handler' > collect2: error: ld returned 1 exit status 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) Christian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Build Failure on Cygwin 2020-10-19 17:26 Build Failure on Cygwin Joel Sherrill 2020-10-19 17:42 ` Christian Biesinger @ 2020-10-19 17:46 ` Hannes Domani 2020-10-19 19:33 ` Joel Sherrill 1 sibling, 1 reply; 9+ messages in thread From: Hannes Domani @ 2020-10-19 17:46 UTC (permalink / raw) To: gdb, Joel Sherrill Am Montag, 19. Oktober 2020, 19:26:28 MESZ hat Joel Sherrill <joel@rtems.org> Folgendes geschrieben: > Hi > > I am getting a build failure on Cygwin > > /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x5502): > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS > init function for thread_local_segv_handler' > /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x551b): > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS > init function for thread_local_segv_handler' > collect2: error: ld returned 1 exit status > > This is a build targeting RTEMS based on a tarball fetched from > git:(sourceware-mirror-binutils-gdb-8a6e98c). It should correspond to this > recent commit: > > ommit 8a6e98c4a3049d7fb8ffc24b231e8cf3577fd90a > Author: GDB Administrator <gdbadmin@sourceware.org> > Date: Mon Oct 12 00:00:07 2020 +0000 > > Automatic date update in version.in > > Any suggestions on how to fix this? Isn't that the same problem you already started a thread about in march?: https://sourceware.org/pipermail/gdb/2020-March/048436.html And it ended with you planning to file a gdb bug. Hannes ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Build Failure on Cygwin 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 0 siblings, 2 replies; 9+ messages in thread From: Joel Sherrill @ 2020-10-19 19:33 UTC (permalink / raw) To: Hannes Domani; +Cc: gdb On Mon, Oct 19, 2020 at 12:46 PM Hannes Domani <ssbssa@yahoo.de> wrote: > Am Montag, 19. Oktober 2020, 19:26:28 MESZ hat Joel Sherrill < > joel@rtems.org> Folgendes geschrieben: > > > Hi > > > > I am getting a build failure on Cygwin > > > > > /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x5502): > > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS > > init function for thread_local_segv_handler' > > > /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x551b): > > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS > > init function for thread_local_segv_handler' > > collect2: error: ld returned 1 exit status > > > > This is a build targeting RTEMS based on a tarball fetched from > > git:(sourceware-mirror-binutils-gdb-8a6e98c). It should correspond to > this > > recent commit: > > > > ommit 8a6e98c4a3049d7fb8ffc24b231e8cf3577fd90a > > Author: GDB Administrator <gdbadmin@sourceware.org> > > Date: Mon Oct 12 00:00:07 2020 +0000 > > > > Automatic date update in version.in > > > > Any suggestions on how to fix this? > > Isn't that the same problem you already started a thread about in march?: > https://sourceware.org/pipermail/gdb/2020-March/048436.html > > And it ended with you planning to file a gdb bug. > Yes and I have completely forgotten about that. I sent that about a week after I started working from home. Apparently I forgot to file this. I will file it. Hopefully that will prod someone to fix it. 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. I'm not sure of the solution and based on the results from a Google search people just hack around it. It does need a proper solution. --joel > > > Hannes > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Build Failure on Cygwin 2020-10-19 19:33 ` Joel Sherrill @ 2020-10-19 23:03 ` Joel Sherrill 2020-10-20 11:39 ` Christian Biesinger 1 sibling, 0 replies; 9+ messages in thread From: Joel Sherrill @ 2020-10-19 23:03 UTC (permalink / raw) To: Hannes Domani; +Cc: gdb Following up, I have filed a ticket. GDB does not build native or cross on Cygwin. Same error both ways. You have to build with --disable-werror or it fails before it gets that far when building natively. I have filed two tickets about this. --joel On Mon, Oct 19, 2020 at 2:33 PM Joel Sherrill <joel@rtems.org> wrote: > > > On Mon, Oct 19, 2020 at 12:46 PM Hannes Domani <ssbssa@yahoo.de> wrote: > >> Am Montag, 19. Oktober 2020, 19:26:28 MESZ hat Joel Sherrill < >> joel@rtems.org> Folgendes geschrieben: >> >> > Hi >> > >> > I am getting a build failure on Cygwin >> > >> > >> /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x5502): >> > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS >> > init function for thread_local_segv_handler' >> > >> /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x551b): >> > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS >> > init function for thread_local_segv_handler' >> > collect2: error: ld returned 1 exit status >> > >> > This is a build targeting RTEMS based on a tarball fetched from >> > git:(sourceware-mirror-binutils-gdb-8a6e98c). It should correspond to >> this >> > recent commit: >> > >> > ommit 8a6e98c4a3049d7fb8ffc24b231e8cf3577fd90a >> > Author: GDB Administrator <gdbadmin@sourceware.org> >> > Date: Mon Oct 12 00:00:07 2020 +0000 >> > >> > Automatic date update in version.in >> > >> > Any suggestions on how to fix this? >> >> Isn't that the same problem you already started a thread about in march?: >> https://sourceware.org/pipermail/gdb/2020-March/048436.html >> >> And it ended with you planning to file a gdb bug. >> > > Yes and I have completely forgotten about that. I sent that about a week > after > I started working from home. Apparently I forgot to file this. I will file > it. > Hopefully that will prod someone to fix it. > > 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. > > I'm not sure of the solution and based on the results from a Google > search people just hack around it. It does need a proper solution. > > --joel > >> >> >> Hannes >> > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Build Failure on Cygwin 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 1 sibling, 1 reply; 9+ messages in thread From: Christian Biesinger @ 2020-10-20 11:39 UTC (permalink / raw) To: joel; +Cc: Hannes Domani, gdb 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 differently? Christian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Build Failure on Cygwin 2020-10-20 11:39 ` Christian Biesinger @ 2020-10-20 13:35 ` Joel Sherrill 2020-10-20 18:23 ` Hannes Domani 0 siblings, 1 reply; 9+ messages in thread From: Joel Sherrill @ 2020-10-20 13:35 UTC (permalink / raw) To: Christian Biesinger; +Cc: Hannes Domani, gdb 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? --joel > Christian > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Build Failure on Cygwin 2020-10-20 13:35 ` Joel Sherrill @ 2020-10-20 18:23 ` Hannes Domani 2020-10-20 19:18 ` Joel Sherrill 0 siblings, 1 reply; 9+ messages in thread From: Hannes Domani @ 2020-10-20 18:23 UTC (permalink / raw) To: Christian Biesinger, Joel Sherrill; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Build Failure on Cygwin 2020-10-20 18:23 ` Hannes Domani @ 2020-10-20 19:18 ` Joel Sherrill 0 siblings, 0 replies; 9+ messages in thread From: Joel Sherrill @ 2020-10-20 19:18 UTC (permalink / raw) To: Hannes Domani; +Cc: Christian Biesinger, gdb 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 > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-10-20 19:19 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-19 17:26 Build Failure on Cygwin 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 2020-10-20 19:18 ` Joel Sherrill
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).