From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cp165172.hpdns.net (cp165172.hpdns.net [91.238.165.172]) by sourceware.org (Postfix) with ESMTPS id 3EDB23851C0D for ; Sat, 23 May 2020 22:17:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3EDB23851C0D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dyxyl.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=qqxnjvamvxwx@dyxyl.com DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dyxyl.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zqelVIsHPJvK6fYUrQrSQrdocK2ilCVv/k9fEGciMcs=; b=pv5qHv2aiZWkxbvgDgp23vnaSw 9wScpbnaSeymJBkF2xMQJyi7KDTYp3ckCHAh9AABk4Yu6vgucWxuy76BghGXmW1Piv0j6lm261zyW 3VKzKs1nAxHvfXqiHLHmfQYULM6HnBIsSV+XBuwTc0X2Z2D1piZ6tIgdNZk3t+Y0o9fc=; Received: from cpc92314-cmbg19-2-0-cust794.5-4.cable.virginm.net ([82.11.187.27]:40234 helo=localhost.localdomain) by cp165172.hpdns.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jccSn-006gww-LH; Sat, 23 May 2020 23:17:53 +0100 Received: by localhost.localdomain (Postfix, from userid 597) id 43DBC601DC; Sat, 23 May 2020 23:17:53 +0100 (BST) From: Martin Simmons To: Chris Nicol Cc: simark@simark.ca, gdb@sourceware.org Subject: Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" In-Reply-To: (message from Chris Nicol on Sat, 23 May 2020 12:29:49 -0600) References: <052613da-fdbe-707b-3a52-da7ce437d424@uleth.ca> <1b20f6d8-9736-02d8-73dc-bc4843e36ed3@simark.ca> <198ff4bc-8195-750e-84f5-e3d76974a223@uleth.ca> <88abec76-ad36-1562-d93b-d1159430bf2d@uleth.ca> <04509e3f-e5d9-72fb-1b1a-6d58a08482a2@simark.ca> <359bdbb1-c4ab-b89c-6d0a-f18025c64da8@simark.ca> Date: Sat, 23 May 2020 23:17:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-cPanel-MailScanner-Information: Please contact the ISP for more information X-cPanel-MailScanner-ID: 1jccSn-006gww-LH X-cPanel-MailScanner: Found to be clean X-cPanel-MailScanner-SpamCheck: X-cPanel-MailScanner-From: qqxnjvamvxwx@dyxyl.com X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HK_RANDOM_ENVFROM, HK_RANDOM_FROM, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cp165172.hpdns.net X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dyxyl.com X-Get-Message-Sender-Via: cp165172.hpdns.net: authenticated_id: dyxyl/from_h X-Authenticated-Sender: cp165172.hpdns.net: qqxnjvamvxwx@dyxyl.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: Sat, 23 May 2020 22:17:58 -0000 Hi Chris, Yes, the architecture is detected from the binary if given, otherwise it defaults to the main architecture. BTW, have you tried building devel/gdb from the /usr/ports tree? That is the normal way to get any specific tweaks that the FreeBSD project already knows about. I can't give you comprehensive instructions on how to debug the nested gdb. I think you should start by looking at the function gdbarch_init_osabi in gdb/osabi.c to see what it does. In summary, it is looking in the list gdb_osabi_handler_list for something that matches the argument named info. It only finds a match if the osabi is the same and it has an acceptable arch_info (the function can_run_code_for). It prints the warning if it doesn't find a match. The command sequence to start debugging it is something like this: break gdbarch_init_osabi run It should then stop at the breakpoint, where it is useful to do: print info print *info.bfd_arch_info set $tmp=gdb_osabi_handler_list while $tmp print *$tmp print *$tmp->arch_info set $tmp=$tmp->next end That might be enough to find why there is no match, but otherwise you have to repeatedly use the step command and print other things that the code is examining. __Martin >>>>> On Sat, 23 May 2020 12:29:49 -0600, Chris Nicol said: > > Martin, > > Thanks for the follow-up. "show osabi" indicates "The current OS ABI is > "auto" (currently "FreeBSD"). The default OS ABI is "FreeBSD")." > Not very informative, as "FreeBSD" seems to be what gdb is having > trouble with when loading. Perhaps there is some configuration parameter > I should be setting when I run ./configure? > > I have run the nested gdb gdb llvm... as you suggest, but am not sure > where to go from there. What command sequence do I need to use to step > through osabi initialisation, then "running code for"? > > If I run gdb on its own with no arguments, "show architecture" indicates > "sparc". If I run it and load a binary, then run "show architecture", > the result is "sparc:v9". But the problem seems to be with the > identification of the OS? > > Thanks. > > Chris. > > > On 5/23/2020 11:40 AM, Martin Simmons wrote: > > 64-bit SPARC is always at least v9. > > > > What do the "show osabi" and "set osabi" commands show? > > > > Can you run gdb under gdb? I.e. (adjusting the paths as required): > > > > gdb/gdb --args gdb/gdb llvm-tblgen llvm-tblgen.core > > > > Then use the outer gdb to step through gdbarch_init_osabi and > > can_run_code_for in the inner gdb to see why none of the gdbarch_info > > objects match before it prints that warning? You might need to > > configure gdb with CFLAGS=-g CXXFLAGS=-g to get useful debugging info. > > > > __Martin > > > > > >>>>>> On Fri, 22 May 2020 13:35:15 -0600, Chris Nicol said: > >> > >> Simon, > >> > >> This link: > >> > >> https://wiki.freebsd.org/201110DevSummit?action=AttachFile&do=get&target=sparc64_status_201110DevSummit.pdf > >> > >> at page 4, "CPU Type" makes me suspicious that v9 does not correctly > >> characterise my processor. In that same document, there is reference to > >> support for "UltraSparc, UltraParc III and V9" processors, whereas the > >> SunBlade 100 I am using is referenced as having an UltrasSparcIIe > >> processor, which is maybe not "v9"? v9 is possibly something else, such > >> as UltraSparc III+. There are sparc64-fbsd-nat.o, sparc64-fbsd.tdep.o , > >> sparc64-nat.o and sparc64-tdep.o object files in my build directory. > >> > >> > >> Chris. > >> On 5/22/2020 12:51 PM, Simon Marchi wrote: > >>> On 2020-05-22 2:22 p.m., Chris Nicol wrote: > >>>> Dear Simon, > >>>> > >>>> Thanks for your reply. I went ahead and completed the build of > >>>> gbd-9.1, which had been the original plan. With the gdb-9.1 > >>>> executable, I re-ran it against the llvm-tblgen binary and its core > >>>> dump, with the same result as in gdb-8.3. So this is progress of a > >>>> sort, I suppose. > >>>> > >>>> Taking now the gdb-9.1 and loading gcc9 into the debugger, then > >>>> "show architecture" yields "The target architecture is set > >>>> automatically (currently sparc:v9)". The system I am using is based > >>>> on the 500-MHz UltraSPARC IIe processor. So maybe this setting, > >>>> sparc:v9, is wrong for this platform? > >>>> > >>>> Best wishes, > >>>> > >>>> Chris. > >>> > >>> I'm not really familiar with sparc machines... does that values sound > >>> good to you? Does it seem to match the machine you have? > >>> > >>> In any case, that seems to match the osabi registration line in > >>> sparc64-fbsd-tdep.c: > >>> > >>> gdbarch_register_osabi (bfd_arch_sparc, bfd_mach_sparc_v9, > >>> GDB_OSABI_FREEBSD, sparc64fbsd_init_abi); > >>> > >>> Is the file sparc64-fbsd-tdep.c being compiled? In other words, does > >>> the file gdb/sparc64-fbsd-tdep.o exist in your build directory? > >>> > >>> Simon > >>> > >> > >> > >> > >> > >> > > > >