From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by sourceware.org (Postfix) with ESMTPS id 21C4B3850414 for ; Tue, 20 Oct 2020 19:19:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 21C4B3850414 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joel.sherrill@gmail.com Received: by mail-ej1-f49.google.com with SMTP id h24so4365083ejg.9 for ; Tue, 20 Oct 2020 12:19:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=1pr4uyRSq3gk8YRq9a4s0qcFN9t3n+1WYs32f9T9P2M=; b=dTgCUcm3m4zSb4twAgdriqM9SAIgFAjlKbRkSgMJBtq28pHrBoy1NAqhJfqv8MBptg Kc+tv2An5S8ZsK+YVkj20wDKshgZyhg3Mq7RBp7xzVeJaLmWkE74S17C23zAHIfDtAGs ZfE46pLMRVViDJZJ9pY/uHJiNJ0gttkbz0RS+d2YXa9x6YTSLsO/er1j/jjmHFFIVpZ4 el+M6EA+a49veRnJ9OG9c3Zi4Kw/XaiNcCqcQ9oMMbcdbjoaHv65GQIp0pXEpnVSOziT LARfmDupyfM7XifMAHpKYyAnE1iR3RxlmjRuvrbKl07aTneSsgED72DBFTFjI26PiIIh qDxQ== X-Gm-Message-State: AOAM53327R8IqYGeVm5Fw3Ik/Zibo+ReCIfrRwuZCXFci+T8LTIos/lh 5dKeXdQbLcVc8o3Kg65JPFQ/w7MOOEU= X-Google-Smtp-Source: ABdhPJzVaZlyNxAlwqyhPlWGdx6lK4Fbz3YzzuWsrQ7Y9miQ+jw7ArG5PylGj9ODHp935HCE41o8qw== X-Received: by 2002:a17:906:3cc:: with SMTP id c12mr4708586eja.210.1603221546618; Tue, 20 Oct 2020 12:19:06 -0700 (PDT) Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com. [209.85.218.43]) by smtp.gmail.com with ESMTPSA id c5sm3364108edj.89.2020.10.20.12.19.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Oct 2020 12:19:06 -0700 (PDT) Received: by mail-ej1-f43.google.com with SMTP id qp15so4399970ejb.3 for ; Tue, 20 Oct 2020 12:19:06 -0700 (PDT) X-Received: by 2002:a17:906:f8d4:: with SMTP id lh20mr4693041ejb.188.1603221546154; Tue, 20 Oct 2020 12:19:06 -0700 (PDT) MIME-Version: 1.0 References: <339649978.1780844.1603129592020@mail.yahoo.com> <2088332346.2505262.1603218219278@mail.yahoo.com> In-Reply-To: <2088332346.2505262.1603218219278@mail.yahoo.com> Reply-To: joel@rtems.org From: Joel Sherrill Date: Tue, 20 Oct 2020 14:18:52 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Build Failure on Cygwin To: Hannes Domani Cc: Christian Biesinger , "gdb@sourceware.org" X-Spam-Status: No, score=-3032.0 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 19:19:09 -0000 On Tue, Oct 20, 2020 at 1:23 PM Hannes Domani 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 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 >