From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 2A26F388F058 for ; Wed, 24 Jun 2020 10:27:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2A26F388F058 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=none smtp.mailfrom=ro@cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 271DAA3A45 for ; Wed, 24 Jun 2020 12:27:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH4eqE3h_72s for ; Wed, 24 Jun 2020 12:27:39 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p4fddbb33.dip0.t-ipconnect.de [79.221.187.51]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id A77ACA3F07 for ; Wed, 24 Jun 2020 12:27:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1592994459; bh=6UD9zsITq5PbKgSDDDHeq6uCT0LkqwHNZ9rCc5Zwr7U=; h=From:To:Subject:References:Date:In-Reply-To:From; b=YudHxFGNQMB6NezMYkKV1RxOfUgu6QCAP1AB0sRMfQ08YOI+r5K5rLYWTOb0V3lq3 lnDztAQTTzDPneLn3S9u4FRautI7W8Sn+rAbIQ9hkO76eApxxv/NDJu5q6UvM7a9rt 4vfpYm95iecF4nlY6/dIacL7uPALfLriKu3ZgQaX3kDgaMWn9gkYbF35GkPZpps4Dw BROEY5UjK5+VC0Pox8SVMp/q2No6wIFinq3qCnsa0aKj//wJzgWu7U9WaURSit66e4 3rJpUulk7XBItpJ2sQYjO3ls040iyyLr6jL7KMXpg3kzxByZ4uhbIDV0XUGiFuHXST Uw1AaXZIKqe5g== From: Rainer Orth To: gdb-patches@sourceware.org Subject: Re: [RFC][PATCH] Move common handlers to sol2_init_abi References: Date: Wed, 24 Jun 2020 12:27:38 +0200 In-Reply-To: (Rainer Orth's message of "Tue, 23 Jun 2020 15:15:57 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3791.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 10:27:42 -0000 Rainer Orth writes: > There's some overlap and duplication between 32 and 64-bit Solaris/SPARC > and x86 tdep files, in particular > > sol2_core_pid_to_str > *_sol2_sigtramp_p > sol2_skip_solib_resolver > *_sol2_static_transform_name (forgotten on amd64) > set_gdbarch_sofun_address_maybe_missing (likewise) > > This patch avoids this by centralizing common code in sol2-tdep.c. > While sparc_sol2_pc_in_sigtramp and sparc_sol2_static_transform_name > were declared in the shared sparc-tdep.h, they were only used in Solaris > files. > > However, I just discovered that there are two targets that would break > with this patch: both sparc-*-linux* and sparc64-*-linux* include > sparc-sol2-tdep.o and sparc64-sol2-tdep.o in configure.tgt. With the > new call to sol2_init_abi which only lives in sol2-tdep.o, gdb would > fail to link. I have no idea what business they have with > Solaris-specific files: I suspect that's to allow debugging of > Solaris/SPARC binaries (i.e. GDB_OSABI_SOLARIS). What should I do about > this? Maybe I also could include sol2-tdep.o on Linux/SPARC, but is > this TRT? AFAICS those files received only mechanical changes over the > last two years (haven't looked further), and I have no way of testing > changes. I must have been half asleep when I wrote this: sparc*-*-linux* already *does* link sol2-tdep.o. I've now verified (on gcc202 in the GCC compile farm) that gdb links without and with my patch, so I'm going to install the patch soon. I couldn't do a proper regtest, however, since even unmodified master ran into a tight loop testing gdb.base/testenv.exp (it went up to 4.4+ million iterations before I noticed the problem). I cannot report the details now since the system has been unaccessible for two days. The other questions raised in the patch submission still hold, though. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University