Build Failure on Cygwin

Build Failure on Cygwin

[Joel Sherrill]

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

Re: Build Failure on Cygwin

[Christian Biesinger]

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

Re: Build Failure on Cygwin

[Hannes Domani]

 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

Re: Build Failure on Cygwin

[Joel Sherrill]

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
>

Re: Build Failure on Cygwin

[Joel Sherrill]

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
>>
>

Re: Build Failure on Cygwin

[Christian Biesinger]

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

Re: Build Failure on Cygwin

[Joel Sherrill]

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
>

Re: 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

Re: Build Failure on Cygwin

[Joel Sherrill]

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
>