From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by sourceware.org (Postfix) with ESMTPS id 474853857C7B for ; Tue, 20 Oct 2020 13:35:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 474853857C7B 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-ed1-f43.google.com with SMTP id 33so1841668edq.13 for ; Tue, 20 Oct 2020 06:35:51 -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=ZMGSxNu2Yl6RRksfic+RsAcd14j8RO4x7dDLPVDNKTw=; b=Qz7nDW+hTYD7mrBHAqIXeFhal7ovo+dR/Q4xLKd51l23Gr82No78KzQcDsVn3J2LzI I0A80jWh8L7ZUJeP2bRBcSFn42MZ0xiqJ4OH5B2LSfLrCuXgE8YdMImp42ZFsqlLuvkD w9ffXjJ7zNG8EeDzRByCM6oexnizGGzSfK9JvaWQjLrOJPpkwFyzS8ZVdY0JdyVZUeno dZW0no1DOSXfsx9XJ8iMAaMN3LRGTZkPXXWbjZXEfuT4AHMkwx3BX5yg159SDx65Pvcc QKyy4wElFLWpLk+fhfjqYiH6kwFDXhLgNrYHjal+iJ45MwSnsWL9ke4outk+C+nimO4c rzXA== X-Gm-Message-State: AOAM531DA2DCBH7U6gq5mg6P5dnF3o3qt5WLJYp+0GgYulXWnKgt92WV GAeycwXJeX2MCIv7f9ZY1XkcTAyXc6s= X-Google-Smtp-Source: ABdhPJxaGlugBo/0YWRMDZlHM/BkblqHEZDTouP/v7DFMHB5ZsGCypVMkWfkNhtskFWDMPOW772/vQ== X-Received: by 2002:aa7:c910:: with SMTP id b16mr2728462edt.286.1603200950074; Tue, 20 Oct 2020 06:35:50 -0700 (PDT) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com. [209.85.208.52]) by smtp.gmail.com with ESMTPSA id m25sm2461498edp.36.2020.10.20.06.35.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Oct 2020 06:35:49 -0700 (PDT) Received: by mail-ed1-f52.google.com with SMTP id x1so1886060eds.1 for ; Tue, 20 Oct 2020 06:35:49 -0700 (PDT) X-Received: by 2002:a05:6402:4:: with SMTP id d4mr2949704edu.78.1603200949659; Tue, 20 Oct 2020 06:35:49 -0700 (PDT) MIME-Version: 1.0 References: <339649978.1780844.1603129592020@mail.yahoo.com> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Tue, 20 Oct 2020 08:35:37 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Build Failure on Cygwin To: Christian Biesinger Cc: Hannes Domani , "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_H2, 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 13:35:52 -0000 On Tue, Oct 20, 2020 at 6:39 AM Christian Biesinger 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? --joel > Christian >