* gdb-9.1 Fails to build: "invalid cast to abstract class type" @ 2020-05-20 18:24 Chris Nicol 2020-05-21 14:12 ` Simon Marchi 0 siblings, 1 reply; 19+ messages in thread From: Chris Nicol @ 2020-05-20 18:24 UTC (permalink / raw) To: gdb Hello, I am trying to build a new version of the debugger on a SunBlade 100 running FreeBSD 12.1. This build fails with the following complaint: CXX sparc64-fbsd-nat.o In file included from ../../gdb/sparc64-fbsd-nat.c:26: ../../gdb/sparc-nat.h: In instantiation of 'target_xfer_status sparc_target<BaseTarget>::xfer_partial(target_object, const char*, gdb_byte*, const gdb_byte*, ULONGEST, ULONGEST, ULONGEST*) [with BaseTarget = fbsd_nat_target; gdb_byte = unsigned char; ULONGEST = long unsigned int]': ../../gdb/sparc-nat.h:67:27: required from here ../../gdb/sparc-nat.h:78:12: error: invalid cast to abstract class type 'fbsd_nat_target' 78 | return BaseTarget (object, annex, readbuf, writebuf, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 79 | offset, len, xfered_len); | ~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ../../gdb/sparc64-fbsd-nat.c:24: ../../gdb/fbsd-nat.h:36:7: note: because the following virtual functions are pure within 'fbsd_nat_target': 36 | class fbsd_nat_target : public inf_ptrace_target | ^~~~~~~~~~~~~~~ In file included from ../../gdb/inf-ptrace.h:23, from ../../gdb/fbsd-nat.h:23, from ../../gdb/sparc64-fbsd-nat.c:24: ../../gdb/inf-child.h:42:8: note: 'virtual void inf_child_target::fetch_registers(regcache*, int)' 42 | void fetch_registers (struct regcache *, int) override = 0; | ^~~~~~~~~~~~~~~ ../../gdb/inf-child.h:43:8: note: 'virtual void inf_child_target::store_registers(regcache*, int)' 43 | void store_registers (struct regcache *, int) override = 0; | ^~~~~~~~~~~~~~~ gmake[2]: *** [Makefile:1656: sparc64-fbsd-nat.o] Error 1 gmake[2]: Leaving directory '/usr/home/nicolc/gdb/gdb-9.1/build/gdb' gmake[1]: *** [Makefile:9563: all-gdb] Error 2 gmake[1]: Leaving directory '/usr/home/nicolc/gdb/gdb-9.1/build' gmake: *** [Makefile:851: all] Error 2 Can anyone provide insight into what is going on here, please? Thank you. Chris. -- ______________________________________________________________________ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb-9.1 Fails to build: "invalid cast to abstract class type" 2020-05-20 18:24 gdb-9.1 Fails to build: "invalid cast to abstract class type" Chris Nicol @ 2020-05-21 14:12 ` Simon Marchi 2020-05-22 3:55 ` Chris Nicol 2020-05-23 16:29 ` gdb-9.1 Fails to build: "invalid cast to abstract class type" Joel Brobecker 0 siblings, 2 replies; 19+ messages in thread From: Simon Marchi @ 2020-05-21 14:12 UTC (permalink / raw) To: Chris Nicol, gdb On 2020-05-20 2:24 p.m., Chris Nicol wrote: > Hello, > > I am trying to build a new version of the debugger on a SunBlade 100 running FreeBSD 12.1. This build fails with the following complaint: > > CXX sparc64-fbsd-nat.o > In file included from ../../gdb/sparc64-fbsd-nat.c:26: > ../../gdb/sparc-nat.h: In instantiation of 'target_xfer_status sparc_target<BaseTarget>::xfer_partial(target_object, const char*, gdb_byte*, const gdb_byte*, ULONGEST, ULONGEST, ULONGEST*) [with BaseTarget = fbsd_nat_target; gdb_byte = unsigned char; ULONGEST = long unsigned int]': > ../../gdb/sparc-nat.h:67:27: required from here > ../../gdb/sparc-nat.h:78:12: error: invalid cast to abstract class type 'fbsd_nat_target' > 78 | return BaseTarget (object, annex, readbuf, writebuf, > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 79 | offset, len, xfered_len); > | ~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from ../../gdb/sparc64-fbsd-nat.c:24: > ../../gdb/fbsd-nat.h:36:7: note: because the following virtual functions are pure within 'fbsd_nat_target': > 36 | class fbsd_nat_target : public inf_ptrace_target > | ^~~~~~~~~~~~~~~ > In file included from ../../gdb/inf-ptrace.h:23, > from ../../gdb/fbsd-nat.h:23, > from ../../gdb/sparc64-fbsd-nat.c:24: > ../../gdb/inf-child.h:42:8: note: 'virtual void inf_child_target::fetch_registers(regcache*, int)' > 42 | void fetch_registers (struct regcache *, int) override = 0; > | ^~~~~~~~~~~~~~~ > ../../gdb/inf-child.h:43:8: note: 'virtual void inf_child_target::store_registers(regcache*, int)' > 43 | void store_registers (struct regcache *, int) override = 0; > | ^~~~~~~~~~~~~~~ > gmake[2]: *** [Makefile:1656: sparc64-fbsd-nat.o] Error 1 > gmake[2]: Leaving directory '/usr/home/nicolc/gdb/gdb-9.1/build/gdb' > gmake[1]: *** [Makefile:9563: all-gdb] Error 2 > gmake[1]: Leaving directory '/usr/home/nicolc/gdb/gdb-9.1/build' > gmake: *** [Makefile:851: all] Error 2 > > > Can anyone provide insight into what is going on here, please? Thank you. > > Chris. > -- > ______________________________________________________________________ > This has been fixed by this commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c6a42d11acf2d485bf70d76eda76fd005fcd6825 So if you use the master branch, you shouldn't see this error. GDB 9.2 (the bugfix release of 9.1) will be out soon, we could probably cherry-pick that commit in that branch if that helps you. Simon ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb-9.1 Fails to build: "invalid cast to abstract class type" 2020-05-21 14:12 ` Simon Marchi @ 2020-05-22 3:55 ` Chris Nicol 2020-05-22 5:56 ` gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" Chris Nicol 2020-05-23 16:29 ` gdb-9.1 Fails to build: "invalid cast to abstract class type" Joel Brobecker 1 sibling, 1 reply; 19+ messages in thread From: Chris Nicol @ 2020-05-22 3:55 UTC (permalink / raw) To: gdb Dear Simon, Thanks for your helpful advice. Before receiving it, I retrieved version 8.3 looking for a different result, and your advice arrived just as that version crashed for the same reason. So, I did the edit on the relevant code, and this version failed at the very end when doing all the linking. I was able to find the fix for that fail from git, and built the 8.3 successfully. I am now in the process of building 9.1 with the fix you have noted. The SunBlade 100 is old, so this will take some time, but I am pretty sure it will work now. Thanks for the offer of the 9.2. I will just wait until that is formally released. I have been pulling these src files from ftp.gnu.org, but it might be a better idea to go get the code from git, as it would incorporate any intermediate bug fixes? The reason I wanted the new version of debugger was because the older one I had (a stock 6.1.1, which came with the FreeBSD 12.1 I am running) would not run against some core dumps I had from llvm-tblgen in the build of llvm90. This was being built with gcc9, a gcc9 which I built and installed on the SunBlade 100 from the /usr/ports tree. When I run the gdb-8.3 against that llvn-tblgen.core, I get an initial message "A handler for the OSI ABI "FreeBSD" is not built into this configuration of GDB. Attempting to continue with the default sparc settings". The debugger does not then provide any useful results, simply indicating that a seg fault happened at: #0 0000000000000000 in ?? () I think this is because the gdb can't figure out the arch of my SunBlade? I read some other posts of a similar nature that generated this message, which I think is built into the test code to identify architecture. I believe there is a simple workaround for this, but it is beyond my ken as a mere economist dabbling in things I should leave alone ;) Can anyone of the list provide any advice on this, please? Thank you. Sincerely, Chris. > On 5/21/2020 8:12 AM, Simon Marchi wrote: >> >> This has been fixed by this commit: >> >> >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c6a42d11acf2d485bf70d76eda76fd005fcd6825 >> >> >> So if you use the master branch, you shouldn't see this error. >> >> GDB 9.2 (the bugfix release of 9.1) will be out soon, we could probably >> cherry-pick that commit in that branch if that helps you. >> >> Simon >> > > > ^ permalink raw reply [flat|nested] 19+ messages in thread
* gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-22 3:55 ` Chris Nicol @ 2020-05-22 5:56 ` Chris Nicol 2020-05-22 17:36 ` Simon Marchi 0 siblings, 1 reply; 19+ messages in thread From: Chris Nicol @ 2020-05-22 5:56 UTC (permalink / raw) To: gdb Dear List, My system - SunBlade 100 running FreeBSD 12.1 had a stock gdb 6.1.1 version of the debugger, which came with the FreeBSD 12.1 I am running. This version would not would not run against some core dumps I had from llvm-tblgen in the build of llvm90. This was being built with gcc9, a gcc9 which I built and installed on the SunBlade 100 from the /usr/ports tree. When I run the gdb-8.3 against that llvn-tblgen.core, I get an initial message "A handler for the OSI ABI "FreeBSD" is not built into this configuration of GDB. Attempting to continue with the default sparc settings". The debugger does not then provide any useful results, simply indicating that a seg fault happened at: #0 0000000000000000 in ?? () I think this is because the gdb can't figure out the arch of my SunBlade? It is beg endian, and I think the debugger default is little endian in the stock 8.3 a(and 9.1) build. I read some other posts of a similar nature that generated this message, which I think is built into the test code to identify architecture. I believe there is a simple workaround for this, but it is beyond my ken as a mere economist dabbling in things I should leave alone ;) Can anyone of the list provide any advice on this, please? Thank you. Sincerely, Chris. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-22 5:56 ` gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" Chris Nicol @ 2020-05-22 17:36 ` Simon Marchi 2020-05-22 18:22 ` Chris Nicol 0 siblings, 1 reply; 19+ messages in thread From: Simon Marchi @ 2020-05-22 17:36 UTC (permalink / raw) To: Chris Nicol, gdb On 2020-05-22 1:56 a.m., Chris Nicol wrote: > Dear List, > > My system - SunBlade 100 running FreeBSD 12.1 had a stock gdb 6.1.1 > version of the debugger, which came with the FreeBSD 12.1 I am running. This version would not would not run against some core dumps I had from llvm-tblgen in the > build of llvm90. This was being built with gcc9, a gcc9 which I built > and installed on the SunBlade 100 from the /usr/ports tree. When I run > the gdb-8.3 against that llvn-tblgen.core, I get an initial message "A > handler for the OSI ABI "FreeBSD" is not built into this configuration > of GDB. Attempting to continue with the default sparc settings". Let's start with this, as it's a sign that there's probably something wrong already. There should be a call to gdbarch_register_osabi that registers a handler for the (cpu, os) pair. In sparc64-fbsd-tdep.c, I see this call, for example: gdbarch_register_osabi (bfd_arch_sparc, bfd_mach_sparc_v9, GDB_OSABI_FREEBSD, sparc64fbsd_init_abi); However, maybe your particular machine does not match the machine bfd_arch_sparc / bfd_mach_sparc_v9? What does it show if you load some binary file into GDB, then do "show architecture"? Simon ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-22 17:36 ` Simon Marchi @ 2020-05-22 18:22 ` Chris Nicol 2020-05-22 18:51 ` Simon Marchi 0 siblings, 1 reply; 19+ messages in thread From: Chris Nicol @ 2020-05-22 18:22 UTC (permalink / raw) To: Simon Marchi, gdb 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. On 5/22/2020 11:36 AM, Simon Marchi wrote: > On 2020-05-22 1:56 a.m., Chris Nicol wrote: >> Dear List, >> >> My system - SunBlade 100 running FreeBSD 12.1 had a stock gdb 6.1.1 >> version of the debugger, which came with the FreeBSD 12.1 I am running. This version would not would not run against some core dumps I had from llvm-tblgen in the >> build of llvm90. This was being built with gcc9, a gcc9 which I built >> and installed on the SunBlade 100 from the /usr/ports tree. When I run >> the gdb-8.3 against that llvn-tblgen.core, I get an initial message "A >> handler for the OSI ABI "FreeBSD" is not built into this configuration >> of GDB. Attempting to continue with the default sparc settings". > > Let's start with this, as it's a sign that there's probably something wrong > already. > > There should be a call to gdbarch_register_osabi that registers a handler > for the (cpu, os) pair. In sparc64-fbsd-tdep.c, I see this call, for > example: > > gdbarch_register_osabi (bfd_arch_sparc, bfd_mach_sparc_v9, > GDB_OSABI_FREEBSD, sparc64fbsd_init_abi); > > > However, maybe your particular machine does not match the machine > bfd_arch_sparc / bfd_mach_sparc_v9? What does it show if you load > some binary file into GDB, then do "show architecture"? > > Simon > -- ______________________________________________________________________ Dr. Christopher J. Nicol, Phone: (403) 329-2261 University Librarian and FAX: (403) 329-2234 Professor of Economics, The University of Lethbridge, E-Mail: nicolc@uleth.ca Lethbridge, Alberta, T1K 3M4, CANADA. http://people.uleth.ca/~nicolc ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-22 18:22 ` Chris Nicol @ 2020-05-22 18:51 ` Simon Marchi 2020-05-22 19:35 ` Chris Nicol 0 siblings, 1 reply; 19+ messages in thread From: Simon Marchi @ 2020-05-22 18:51 UTC (permalink / raw) To: Chris Nicol, gdb 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-22 18:51 ` Simon Marchi @ 2020-05-22 19:35 ` Chris Nicol 2020-05-23 17:40 ` Martin Simmons 0 siblings, 1 reply; 19+ messages in thread From: Chris Nicol @ 2020-05-22 19:35 UTC (permalink / raw) To: Simon Marchi, gdb 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-22 19:35 ` Chris Nicol @ 2020-05-23 17:40 ` Martin Simmons 2020-05-23 18:29 ` Chris Nicol 0 siblings, 1 reply; 19+ messages in thread From: Martin Simmons @ 2020-05-23 17:40 UTC (permalink / raw) To: Chris Nicol; +Cc: simark, gdb 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 > > > > > > > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-23 17:40 ` Martin Simmons @ 2020-05-23 18:29 ` Chris Nicol 2020-05-23 22:17 ` Martin Simmons 0 siblings, 1 reply; 19+ messages in thread From: Chris Nicol @ 2020-05-23 18:29 UTC (permalink / raw) To: Martin Simmons; +Cc: simark, gdb 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 >>> >> >> >> >> >> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-23 18:29 ` Chris Nicol @ 2020-05-23 22:17 ` Martin Simmons 2020-05-24 1:55 ` Chris Nicol 0 siblings, 1 reply; 19+ messages in thread From: Martin Simmons @ 2020-05-23 22:17 UTC (permalink / raw) To: Chris Nicol; +Cc: simark, gdb 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 > >>> > >> > >> > >> > >> > >> > > > > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-23 22:17 ` Martin Simmons @ 2020-05-24 1:55 ` Chris Nicol 2020-05-24 14:05 ` Simon Marchi 2020-05-27 21:31 ` Martin Simmons 0 siblings, 2 replies; 19+ messages in thread From: Chris Nicol @ 2020-05-24 1:55 UTC (permalink / raw) To: Martin Simmons; +Cc: simark, gdb Thanks, Martin. Yes, when the gdb_6.1.1 did not work, I first had a look to build the 9.1 in /usr/ports/devel/gdb, but the Makefile indicates NOT_FOR_ARCHS= sparc64, and a comment above it "untested on sparc64, might work". Not encouraged, I went on to build the 9.1 from the gnu source. Maybe I will try the /usr/ports version if I comment out the NOT_FOR_ARCHS, since there might be some tweaks in there that is specific to FreeBSD. I will also try what you are suggesting below. Hard to track down the llvm-tblgen problem when I can't debug why it is seg. faulting... and getting some help on the llvm list has been pretty fruitless. Chris. On 5/23/2020 4:17 PM, Martin Simmons wrote: > 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 -- ______________________________________________________________________ Dr. Christopher J. Nicol, Phone: (403) 329-2261 University Librarian and FAX: (403) 329-2234 Professor of Economics, The University of Lethbridge, E-Mail: nicolc@uleth.ca Lethbridge, Alberta, T1K 3M4, CANADA. http://people.uleth.ca/~nicolc ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-24 1:55 ` Chris Nicol @ 2020-05-24 14:05 ` Simon Marchi 2020-05-27 21:31 ` Martin Simmons 1 sibling, 0 replies; 19+ messages in thread From: Simon Marchi @ 2020-05-24 14:05 UTC (permalink / raw) To: Chris Nicol, Martin Simmons; +Cc: gdb On 2020-05-23 9:55 p.m., Chris Nicol wrote: > Thanks, Martin. Yes, when the gdb_6.1.1 did not work, I first had a look > to build the 9.1 in /usr/ports/devel/gdb, but the Makefile indicates > NOT_FOR_ARCHS= sparc64, and a comment above it "untested on sparc64, > might work". Not encouraged, I went on to build the 9.1 from the gnu > source. Maybe I will try the /usr/ports version if I comment out the > NOT_FOR_ARCHS, since there might be some tweaks in there that is > specific to FreeBSD. > > I will also try what you are suggesting below. Hard to track down the > llvm-tblgen problem when I can't debug why it is seg. faulting... and > getting some help on the llvm list has been pretty fruitless. > > Chris. For the moment, since you don't have a working GDB, it might be easier to just add printfs to understand why function `can_run_code_for` does not return true when it gets at the FreeBSD/sparc64 one. Simon ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-24 1:55 ` Chris Nicol 2020-05-24 14:05 ` Simon Marchi @ 2020-05-27 21:31 ` Martin Simmons [not found] ` <46566349-c023-6a75-7006-268aad4913c6@uleth.ca> 1 sibling, 1 reply; 19+ messages in thread From: Martin Simmons @ 2020-05-27 21:31 UTC (permalink / raw) To: Chris Nicol; +Cc: qqxnjvamvxwx, simark, gdb Hi Chris, Please post of the full output (including all start up messages) of running gdb 9.1 with the llvm-tblgen core file and the gdb commands info all where __Martin >>>>> On Sat, 23 May 2020 19:55:05 -0600, Chris Nicol said: > > Thanks, Martin. Yes, when the gdb_6.1.1 did not work, I first had a look > to build the 9.1 in /usr/ports/devel/gdb, but the Makefile indicates > NOT_FOR_ARCHS= sparc64, and a comment above it "untested on sparc64, > might work". Not encouraged, I went on to build the 9.1 from the gnu > source. Maybe I will try the /usr/ports version if I comment out the > NOT_FOR_ARCHS, since there might be some tweaks in there that is > specific to FreeBSD. > > I will also try what you are suggesting below. Hard to track down the > llvm-tblgen problem when I can't debug why it is seg. faulting... and > getting some help on the llvm list has been pretty fruitless. > > Chris. > > On 5/23/2020 4:17 PM, Martin Simmons wrote: > > 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 > > > -- > ______________________________________________________________________ > Dr. Christopher J. Nicol, Phone: (403) 329-2261 > University Librarian and FAX: (403) 329-2234 > Professor of Economics, > The University of Lethbridge, E-Mail: nicolc@uleth.ca > Lethbridge, Alberta, T1K 3M4, CANADA. http://people.uleth.ca/~nicolc > ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <46566349-c023-6a75-7006-268aad4913c6@uleth.ca>]
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" [not found] ` <46566349-c023-6a75-7006-268aad4913c6@uleth.ca> @ 2020-05-28 10:57 ` Martin Simmons 2020-05-28 14:40 ` Chris Nicol 0 siblings, 1 reply; 19+ messages in thread From: Martin Simmons @ 2020-05-28 10:57 UTC (permalink / raw) To: Chris Nicol; +Cc: qqxnjvamvxwx, simark, gdb Hi Chris, I received your email below but it looks like the mailing list rejected it. For a small amount of output, it is better to just paste the text into the email rather than attaching an rtf. I can see what causes the warning but I think it might be unrelated to the problem of debugging llvm-tblgen. Rather than running gdb inside gdb, please just run: /usr/local/bin/gdb ./llvm-tblgen llvm-tblgen.core and then use the gdb commands: info all where and send the full output. __Martin >>>>> On Wed, 27 May 2020 22:08:03 -0600, Chris Nicol said: > > Martin, > > Thanks for your continued interest. Attached is a rtf with the results > of running the gdb against the llvm-tblgen.core. I ran the sequence of > commands that you suggested, to see if this would shed light on the > osabi problem. > > As I mentioned, I thought I would try to build the /usr/ports version to > see if there was any difference. This produced the attached crash log, > and the *.c file that was responsible for that. The file in question > does not appear in the standard distribution of gdb-9.1, and must be > something that the /usr/ports port has added. Perhaps this sheds some > light on matters. There could be other files in /usr/ports that are > unique to that version of the build. I did not have a chance to check. > Perhaps what is in this brain dump is of some assistance. I hope. > > So many of the /usr/ports builds seem dependent on llvm90. This is a bit > of a nuisance, but I suppose that is the lot of someone using an ancient > piece of hardware, such as the SunBlade 100. I was surprised to find > that I was able to build and run the sylpheed mailer on that system last > night. It not only built quickly, but accepts and delivers my mail, and > looks a lot like thunderbird. The latter which does not build as it, > like firefox, wants to have llvm90 built to support it... > > > Thanks again. > > Chris. > > On 5/27/2020 3:31 PM, Martin Simmons wrote: > > Hi Chris, > > > > Please post of the full output (including all start up messages) of > > running gdb 9.1 with the llvm-tblgen core file and the gdb commands > > > > info all > > where > > > > __Martin > > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-28 10:57 ` Martin Simmons @ 2020-05-28 14:40 ` Chris Nicol 2020-05-28 17:30 ` Martin Simmons 0 siblings, 1 reply; 19+ messages in thread From: Chris Nicol @ 2020-05-28 14:40 UTC (permalink / raw) To: Martin Simmons; +Cc: simark, gdb Thanks, Martin. Here is the log from /usr/local/bin/gdb ./llvm-tblgen llvm-tblgen.core: nicolc@phonix:~/llvm/llvm-9.0.1.src/Mybuilddir/bin % /usr/local/bin/gdb ./llvm-tblgen llvm-tblgen.core /usr/local/bin/gdb: warning: A handler for the OS ABI "FreeBSD" is not built into this configuration of GDB. Attempting to continue with the default sparc settings. GNU gdb (GDB) 9.1 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc64-unknown-freebsd12.1". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./llvm-tblgen... [New LWP 100161] Core was generated by `./llvm-tblgen -version'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000000000 in ?? () (gdb) info all g0 0x0 0 g1 0x0 0 g2 0x417bfddc 1098644956 g3 0x80000000 2147483648 g4 0x4090c000 1083228160 g5 0x408a6688 1082812040 g6 0x0 0 g7 0x408ad910 1082841360 o0 0x408a6698 1082812056 o1 0x2 2 o2 0x10 16 o3 0xf4 244 o4 0x106838 1075256 o5 0x7fffffff 2147483647 sp 0x7fdffffd5e1 0x7fdffffd5e1 o7 0x41017944 1090615620 l0 0x0 0 l1 0x4090c000 1083228160 l2 0x1 1 l3 0x0 0 l4 0x0 0 l5 0x0 0 l6 0x0 0 l7 0x41238000 1092845568 i0 0x884c80 8932480 i1 0x3 3 i2 0x0 0 i3 0x0 0 i4 0x0 0 i5 0x0 0 fp 0x7fdffffd691 0x7fdffffd691 i7 0x409addf0 1083891184 f0 0 (raw 0x00000000) f1 0 (raw 0x00000000) f2 0 (raw 0x00000000) f3 0 (raw 0x00000000) f4 0 (raw 0x00000000) f5 0 (raw 0x00000000) f6 0 (raw 0x00000000) f7 0 (raw 0x00000000) f8 0.00999999978 (raw 0x3c23d70a) f9 0 (raw 0x00000000) f10 2 (raw 0x40000000) f11 0 (raw 0x00000000) --Type <RET> for more, q to quit, c to continue without paging-- f12 0 (raw 0x00000000) f13 0 (raw 0x00000000) f14 0 (raw 0x00000000) f15 0 (raw 0x00000000) f16 0 (raw 0x00000000) f17 0 (raw 0x00000000) f18 0 (raw 0x00000000) f19 0 (raw 0x00000000) f20 0 (raw 0x00000000) f21 0 (raw 0x00000000) f22 0 (raw 0x00000000) f23 0 (raw 0x00000000) f24 0 (raw 0x00000000) f25 0 (raw 0x00000000) f26 0 (raw 0x00000000) f27 0 (raw 0x00000000) f28 0 (raw 0x00000000) f29 0 (raw 0x00000000) f30 0 (raw 0x00000000) f31 0 (raw 0x00000000) f32 0 (raw 0x0000000000000000) f34 0 (raw 0x0000000000000000) f36 0 (raw 0x0000000000000000) f38 0 (raw 0x0000000000000000) f40 0 (raw 0x0000000000000000) f42 0 (raw 0x0000000000000000) f44 0 (raw 0x0000000000000000) f46 0 (raw 0x0000000000000000) f48 0 (raw 0x0000000000000000) f50 0 (raw 0x0000000000000000) f52 0 (raw 0x0000000000000000) f54 0 (raw 0x0000000000000000) f56 0 (raw 0x0000000000000000) f58 0 (raw 0x0000000000000000) f60 0 (raw 0x0000000000000000) f62 0 (raw 0x0000000000000000) pc 0x0 0x0 npc 0x4 0x4 state 0x4400001205 292057780741 fsr 0x0 [ ] fprs 0x3 [ DL DU ] y 0x0 0 cwp 0x5 5 pstate 0x12 [ IE PEF ] --Type <RET> for more, q to quit, c to continue without paging-- asi 0x0 0 ccr 0x44 [ icc.z xcc.z ] d0 0 (raw 0x0000000000000000) d2 0 (raw 0x0000000000000000) d4 0 (raw 0x0000000000000000) d6 0 (raw 0x0000000000000000) d8 5.3776417829113669e-19 (raw 0x3c23d70a00000000) d10 2 (raw 0x4000000000000000) d12 0 (raw 0x0000000000000000) d14 0 (raw 0x0000000000000000) d16 0 (raw 0x0000000000000000) d18 0 (raw 0x0000000000000000) d20 0 (raw 0x0000000000000000) d22 0 (raw 0x0000000000000000) d24 0 (raw 0x0000000000000000) d26 0 (raw 0x0000000000000000) d28 0 (raw 0x0000000000000000) d30 0 (raw 0x0000000000000000) d32 0 (raw 0x0000000000000000) d34 0 (raw 0x0000000000000000) d36 0 (raw 0x0000000000000000) d38 0 (raw 0x0000000000000000) d40 0 (raw 0x0000000000000000) d42 0 (raw 0x0000000000000000) d44 0 (raw 0x0000000000000000) d46 0 (raw 0x0000000000000000) d48 0 (raw 0x0000000000000000) d50 0 (raw 0x0000000000000000) d52 0 (raw 0x0000000000000000) d54 0 (raw 0x0000000000000000) d56 0 (raw 0x0000000000000000) d58 0 (raw 0x0000000000000000) d60 0 (raw 0x0000000000000000) d62 0 (raw 0x0000000000000000) q0 0 (raw 0x00000000000000000000000000000000) q4 0 (raw 0x00000000000000000000000000000000) q8 7.03365791880182537906194915943984275e-298 (raw 0x3c23d70a000000004000000000000000) q12 0 (raw 0x00000000000000000000000000000000) q16 0 (raw 0x00000000000000000000000000000000) q20 0 (raw 0x00000000000000000000000000000000) q24 0 (raw 0x00000000000000000000000000000000) q28 0 (raw 0x00000000000000000000000000000000) q32 0 (raw 0x00000000000000000000000000000000) q36 0 (raw 0x00000000000000000000000000000000) --Type <RET> for more, q to quit, c to continue without paging-- q40 0 (raw 0x00000000000000000000000000000000) q44 0 (raw 0x00000000000000000000000000000000) q48 0 (raw 0x00000000000000000000000000000000) q52 0 (raw 0x00000000000000000000000000000000) q56 0 (raw 0x00000000000000000000000000000000) q60 0 (raw 0x00000000000000000000000000000000) (gdb) where #0 0x0000000000000000 in ?? () #1 0x000000004101794c in __once_proxy () from /usr/local/lib/gcc9/libstdc++.so.6 #2 0x00000000409addf8 in pthread_once () from /lib/libthr.so.3 #3 0x000000000059ca94 in __gthread_once (__once=0x884c80 <mutex_init_flag>, __func=0x41017920 <__once_proxy>) at /usr/local/lib/gcc9/include/c++/sparc64-portbld-freebsd12.1/bits/gthr-default.h:700 #4 0x000000000059ceb0 in std::call_once<void (&)()> (__once=..., __f=@0x59c494: {void (void)} 0x59c494 <initializeMutex()>) at /usr/local/lib/gcc9/include/c++/mutex:683 #5 0x000000000059cc14 in llvm::call_once<void (&)()> (flag=..., F=@0x59c494: {void (void)} 0x59c494 <initializeMutex()>) at /home/nicolc/llvm/llvm-9.0.1.src/include/llvm/Support/Threading.h:104 #6 0x000000000059c52c in getManagedStaticMutex () at /home/nicolc/llvm/llvm-9.0.1.src/lib/Support/ManagedStatic.cpp:30 #7 0x000000000059c5d8 in llvm::ManagedStaticBase::RegisterManagedStatic (this=0x884230 <GlobalParser>, Creator=0x577f08 <llvm::object_creator<(anonymous namespace)::CommandLineParser>::call()>, Deleter=0x577fb0 <llvm::object_deleter<(anonymous namespace)::CommandLineParser>::call(void*)>) at /home/nicolc/llvm/llvm-9.0.1.src/lib/Support/ManagedStatic.cpp:38 #8 0x000000000057784c in llvm::ManagedStatic<(anonymous namespace)::CommandLineParser, llvm::object_creator<(anonymous namespace)::CommandLineParser>, llvm::object_deleter<(anonymous namespace)::CommandLineParser> >::operator* (this=0x884230 <GlobalParser>) at /home/nicolc/llvm/llvm-9.0.1.src/include/llvm/Support/ManagedStatic.h:89 #9 0x0000000000576cc0 in llvm::ManagedStatic<(anonymous namespace)::CommandLineParser, llvm::object_creator<(anonymous namespace)::CommandLineParser>, llvm::object_deleter<(anonymous namespace)::CommandLineParser> >::operator-> (this=0x884230 <GlobalParser>) at /home/nicolc/llvm/llvm-9.0.1.src/include/llvm/Support/ManagedStatic.h:94 #10 0x000000000056921c in llvm::cl::OptionCategory::registerCategory (this=0x883288 <AsmMatcherEmitterCat>) at /home/nicolc/llvm/llvm-9.0.1.src/lib/Support/CommandLine.cpp:468 #11 0x000000000013e508 in llvm::cl::OptionCategory::OptionCategory (this=0x883288 <AsmMatcherEmitterCat>, Name=..., Description=...) at /home/nicolc/llvm/llvm-9.0.1.src/include/llvm/Support/CommandLine.h:199 #12 0x0000000000139400 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/nicolc/llvm/llvm-9.0.1.src/utils/TableGen/AsmMatcherEmitter.cpp:126 #13 0x000000000013951c in _GLOBAL__sub_I_AsmMatcherEmitter.cpp(void) () at /home/nicolc/llvm/llvm-9.0.1.src/utils/TableGen/AsmMatcherEmitter.cpp:3918 #14 0x000000004087f504 in ?? () from /libexec/ld-elf.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) On 5/28/2020 4:57 AM, Martin Simmons wrote: > Hi Chris, > > I received your email below but it looks like the mailing list rejected > it. For a small amount of output, it is better to just paste the text > into the email rather than attaching an rtf. > > I can see what causes the warning but I think it might be unrelated to > the problem of debugging llvm-tblgen. > > Rather than running gdb inside gdb, please just run: > > /usr/local/bin/gdb ./llvm-tblgen llvm-tblgen.core > > and then use the gdb commands: > > info all > where > > and send the full output. > > __Martin -- ______________________________________________________________________ Dr. Christopher J. Nicol, Phone: (403) 329-2261 University Librarian and FAX: (403) 329-2234 Professor of Economics, The University of Lethbridge, E-Mail: nicolc@uleth.ca Lethbridge, Alberta, T1K 3M4, CANADA. http://people.uleth.ca/~nicolc ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-28 14:40 ` Chris Nicol @ 2020-05-28 17:30 ` Martin Simmons 2020-05-28 17:37 ` Chris Nicol 0 siblings, 1 reply; 19+ messages in thread From: Martin Simmons @ 2020-05-28 17:30 UTC (permalink / raw) To: Chris Nicol; +Cc: qqxnjvamvxwx, simark, gdb OK, that shows a reasonable set of registers and a reasonable backtrace. It shows that llvm-tblgen jumped to address 0 from inside __once_proxy for some reason. Gdb seems to be working, at least for this core file, so you can safely ignore the OS ABI warning. __Martin >>>>> On Thu, 28 May 2020 08:40:03 -0600, Chris Nicol said: > > Thanks, Martin. Here is the log from > > /usr/local/bin/gdb ./llvm-tblgen llvm-tblgen.core: > > nicolc@phonix:~/llvm/llvm-9.0.1.src/Mybuilddir/bin % /usr/local/bin/gdb > ./llvm-tblgen llvm-tblgen.core > /usr/local/bin/gdb: warning: A handler for the OS ABI "FreeBSD" is not > built into this configuration > of GDB. Attempting to continue with the default sparc settings. > > GNU gdb (GDB) 9.1 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > Type "show copying" and "show warranty" for details. > This GDB was configured as "sparc64-unknown-freebsd12.1". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from ./llvm-tblgen... > [New LWP 100161] > Core was generated by `./llvm-tblgen -version'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x0000000000000000 in ?? () > (gdb) info all > g0 0x0 0 > g1 0x0 0 > g2 0x417bfddc 1098644956 > g3 0x80000000 2147483648 > g4 0x4090c000 1083228160 > g5 0x408a6688 1082812040 > g6 0x0 0 > g7 0x408ad910 1082841360 > o0 0x408a6698 1082812056 > o1 0x2 2 > o2 0x10 16 > o3 0xf4 244 > o4 0x106838 1075256 > o5 0x7fffffff 2147483647 > sp 0x7fdffffd5e1 0x7fdffffd5e1 > o7 0x41017944 1090615620 > l0 0x0 0 > l1 0x4090c000 1083228160 > l2 0x1 1 > l3 0x0 0 > l4 0x0 0 > l5 0x0 0 > l6 0x0 0 > l7 0x41238000 1092845568 > i0 0x884c80 8932480 > i1 0x3 3 > i2 0x0 0 > i3 0x0 0 > i4 0x0 0 > i5 0x0 0 > fp 0x7fdffffd691 0x7fdffffd691 > i7 0x409addf0 1083891184 > f0 0 (raw 0x00000000) > f1 0 (raw 0x00000000) > f2 0 (raw 0x00000000) > f3 0 (raw 0x00000000) > f4 0 (raw 0x00000000) > f5 0 (raw 0x00000000) > f6 0 (raw 0x00000000) > f7 0 (raw 0x00000000) > f8 0.00999999978 (raw 0x3c23d70a) > f9 0 (raw 0x00000000) > f10 2 (raw 0x40000000) > f11 0 (raw 0x00000000) > --Type <RET> for more, q to quit, c to continue without paging-- > f12 0 (raw 0x00000000) > f13 0 (raw 0x00000000) > f14 0 (raw 0x00000000) > f15 0 (raw 0x00000000) > f16 0 (raw 0x00000000) > f17 0 (raw 0x00000000) > f18 0 (raw 0x00000000) > f19 0 (raw 0x00000000) > f20 0 (raw 0x00000000) > f21 0 (raw 0x00000000) > f22 0 (raw 0x00000000) > f23 0 (raw 0x00000000) > f24 0 (raw 0x00000000) > f25 0 (raw 0x00000000) > f26 0 (raw 0x00000000) > f27 0 (raw 0x00000000) > f28 0 (raw 0x00000000) > f29 0 (raw 0x00000000) > f30 0 (raw 0x00000000) > f31 0 (raw 0x00000000) > f32 0 (raw 0x0000000000000000) > f34 0 (raw 0x0000000000000000) > f36 0 (raw 0x0000000000000000) > f38 0 (raw 0x0000000000000000) > f40 0 (raw 0x0000000000000000) > f42 0 (raw 0x0000000000000000) > f44 0 (raw 0x0000000000000000) > f46 0 (raw 0x0000000000000000) > f48 0 (raw 0x0000000000000000) > f50 0 (raw 0x0000000000000000) > f52 0 (raw 0x0000000000000000) > f54 0 (raw 0x0000000000000000) > f56 0 (raw 0x0000000000000000) > f58 0 (raw 0x0000000000000000) > f60 0 (raw 0x0000000000000000) > f62 0 (raw 0x0000000000000000) > pc 0x0 0x0 > npc 0x4 0x4 > state 0x4400001205 292057780741 > fsr 0x0 [ ] > fprs 0x3 [ DL DU ] > y 0x0 0 > cwp 0x5 5 > pstate 0x12 [ IE PEF ] > --Type <RET> for more, q to quit, c to continue without paging-- > asi 0x0 0 > ccr 0x44 [ icc.z xcc.z ] > d0 0 (raw 0x0000000000000000) > d2 0 (raw 0x0000000000000000) > d4 0 (raw 0x0000000000000000) > d6 0 (raw 0x0000000000000000) > d8 5.3776417829113669e-19 (raw 0x3c23d70a00000000) > d10 2 (raw 0x4000000000000000) > d12 0 (raw 0x0000000000000000) > d14 0 (raw 0x0000000000000000) > d16 0 (raw 0x0000000000000000) > d18 0 (raw 0x0000000000000000) > d20 0 (raw 0x0000000000000000) > d22 0 (raw 0x0000000000000000) > d24 0 (raw 0x0000000000000000) > d26 0 (raw 0x0000000000000000) > d28 0 (raw 0x0000000000000000) > d30 0 (raw 0x0000000000000000) > d32 0 (raw 0x0000000000000000) > d34 0 (raw 0x0000000000000000) > d36 0 (raw 0x0000000000000000) > d38 0 (raw 0x0000000000000000) > d40 0 (raw 0x0000000000000000) > d42 0 (raw 0x0000000000000000) > d44 0 (raw 0x0000000000000000) > d46 0 (raw 0x0000000000000000) > d48 0 (raw 0x0000000000000000) > d50 0 (raw 0x0000000000000000) > d52 0 (raw 0x0000000000000000) > d54 0 (raw 0x0000000000000000) > d56 0 (raw 0x0000000000000000) > d58 0 (raw 0x0000000000000000) > d60 0 (raw 0x0000000000000000) > d62 0 (raw 0x0000000000000000) > q0 0 (raw 0x00000000000000000000000000000000) > q4 0 (raw 0x00000000000000000000000000000000) > q8 7.03365791880182537906194915943984275e-298 (raw > 0x3c23d70a000000004000000000000000) > q12 0 (raw 0x00000000000000000000000000000000) > q16 0 (raw 0x00000000000000000000000000000000) > q20 0 (raw 0x00000000000000000000000000000000) > q24 0 (raw 0x00000000000000000000000000000000) > q28 0 (raw 0x00000000000000000000000000000000) > q32 0 (raw 0x00000000000000000000000000000000) > q36 0 (raw 0x00000000000000000000000000000000) > --Type <RET> for more, q to quit, c to continue without paging-- > q40 0 (raw 0x00000000000000000000000000000000) > q44 0 (raw 0x00000000000000000000000000000000) > q48 0 (raw 0x00000000000000000000000000000000) > q52 0 (raw 0x00000000000000000000000000000000) > q56 0 (raw 0x00000000000000000000000000000000) > q60 0 (raw 0x00000000000000000000000000000000) > (gdb) where > #0 0x0000000000000000 in ?? () > #1 0x000000004101794c in __once_proxy () from > /usr/local/lib/gcc9/libstdc++.so.6 > #2 0x00000000409addf8 in pthread_once () from /lib/libthr.so.3 > #3 0x000000000059ca94 in __gthread_once (__once=0x884c80 > <mutex_init_flag>, __func=0x41017920 <__once_proxy>) > at > /usr/local/lib/gcc9/include/c++/sparc64-portbld-freebsd12.1/bits/gthr-default.h:700 > #4 0x000000000059ceb0 in std::call_once<void (&)()> (__once=..., > __f=@0x59c494: {void (void)} 0x59c494 <initializeMutex()>) > at /usr/local/lib/gcc9/include/c++/mutex:683 > #5 0x000000000059cc14 in llvm::call_once<void (&)()> (flag=..., > F=@0x59c494: {void (void)} 0x59c494 <initializeMutex()>) > at > /home/nicolc/llvm/llvm-9.0.1.src/include/llvm/Support/Threading.h:104 > #6 0x000000000059c52c in getManagedStaticMutex () at > /home/nicolc/llvm/llvm-9.0.1.src/lib/Support/ManagedStatic.cpp:30 > #7 0x000000000059c5d8 in llvm::ManagedStaticBase::RegisterManagedStatic > (this=0x884230 <GlobalParser>, > Creator=0x577f08 <llvm::object_creator<(anonymous > namespace)::CommandLineParser>::call()>, > Deleter=0x577fb0 <llvm::object_deleter<(anonymous > namespace)::CommandLineParser>::call(void*)>) > at /home/nicolc/llvm/llvm-9.0.1.src/lib/Support/ManagedStatic.cpp:38 > #8 0x000000000057784c in llvm::ManagedStatic<(anonymous > namespace)::CommandLineParser, llvm::object_creator<(anonymous > namespace)::CommandLineParser>, llvm::object_deleter<(anonymous > namespace)::CommandLineParser> >::operator* (this=0x884230 <GlobalParser>) > at > /home/nicolc/llvm/llvm-9.0.1.src/include/llvm/Support/ManagedStatic.h:89 > #9 0x0000000000576cc0 in llvm::ManagedStatic<(anonymous > namespace)::CommandLineParser, llvm::object_creator<(anonymous > namespace)::CommandLineParser>, llvm::object_deleter<(anonymous > namespace)::CommandLineParser> >::operator-> (this=0x884230 <GlobalParser>) > at > /home/nicolc/llvm/llvm-9.0.1.src/include/llvm/Support/ManagedStatic.h:94 > #10 0x000000000056921c in llvm::cl::OptionCategory::registerCategory > (this=0x883288 <AsmMatcherEmitterCat>) > at /home/nicolc/llvm/llvm-9.0.1.src/lib/Support/CommandLine.cpp:468 > #11 0x000000000013e508 in llvm::cl::OptionCategory::OptionCategory > (this=0x883288 <AsmMatcherEmitterCat>, Name=..., Description=...) > at > /home/nicolc/llvm/llvm-9.0.1.src/include/llvm/Support/CommandLine.h:199 > #12 0x0000000000139400 in __static_initialization_and_destruction_0 > (__initialize_p=1, __priority=65535) > at > /home/nicolc/llvm/llvm-9.0.1.src/utils/TableGen/AsmMatcherEmitter.cpp:126 > #13 0x000000000013951c in _GLOBAL__sub_I_AsmMatcherEmitter.cpp(void) () > at > /home/nicolc/llvm/llvm-9.0.1.src/utils/TableGen/AsmMatcherEmitter.cpp:3918 > #14 0x000000004087f504 in ?? () from /libexec/ld-elf.so.1 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > (gdb) > > On 5/28/2020 4:57 AM, Martin Simmons wrote: > > Hi Chris, > > > > I received your email below but it looks like the mailing list rejected > > it. For a small amount of output, it is better to just paste the text > > into the email rather than attaching an rtf. > > > > I can see what causes the warning but I think it might be unrelated to > > the problem of debugging llvm-tblgen. > > > > Rather than running gdb inside gdb, please just run: > > > > /usr/local/bin/gdb ./llvm-tblgen llvm-tblgen.core > > > > and then use the gdb commands: > > > > info all > > where > > > > and send the full output. > > > > __Martin > > > -- > ______________________________________________________________________ > Dr. Christopher J. Nicol, Phone: (403) 329-2261 > University Librarian and FAX: (403) 329-2234 > Professor of Economics, > The University of Lethbridge, E-Mail: nicolc@uleth.ca > Lethbridge, Alberta, T1K 3M4, CANADA. http://people.uleth.ca/~nicolc > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" 2020-05-28 17:30 ` Martin Simmons @ 2020-05-28 17:37 ` Chris Nicol 0 siblings, 0 replies; 19+ messages in thread From: Chris Nicol @ 2020-05-28 17:37 UTC (permalink / raw) To: Martin Simmons; +Cc: qqxnjvamvxwx, simark, gdb Martin, OK, great. So I now have an up-to-date gdb, at version 9.1. I will spend some time figuring out how to use it. I am new to this, as you can probably tell... I appreciate all of your assistance. I will take a closer look at some of the llvm-tblgen code. Chris. On 5/28/2020 11:30 AM, Martin Simmons wrote: > > OK, that shows a reasonable set of registers and a reasonable backtrace. > It shows that llvm-tblgen jumped to address 0 from inside __once_proxy > for some reason. > > Gdb seems to be working, at least for this core file, so you can safely > ignore the OS ABI warning. > > __Martin > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: gdb-9.1 Fails to build: "invalid cast to abstract class type" 2020-05-21 14:12 ` Simon Marchi 2020-05-22 3:55 ` Chris Nicol @ 2020-05-23 16:29 ` Joel Brobecker 1 sibling, 0 replies; 19+ messages in thread From: Joel Brobecker @ 2020-05-23 16:29 UTC (permalink / raw) To: Simon Marchi; +Cc: Chris Nicol, gdb > This has been fixed by this commit: > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c6a42d11acf2d485bf70d76eda76fd005fcd6825 > > So if you use the master branch, you shouldn't see this error. > > GDB 9.2 (the bugfix release of 9.1) will be out soon, we could probably > cherry-pick that commit in that branch if that helps you. Thanks for the pointer, Simon. Looking at the patch, it looked obvious to me, so I created a PR for it, and then cherry-picked it in the gdb-9-branch. https://sourceware.org/bugzilla/show_bug.cgi?id=26029 -- Joel ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2020-05-28 17:38 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-20 18:24 gdb-9.1 Fails to build: "invalid cast to abstract class type" Chris Nicol 2020-05-21 14:12 ` Simon Marchi 2020-05-22 3:55 ` Chris Nicol 2020-05-22 5:56 ` gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration" Chris Nicol 2020-05-22 17:36 ` Simon Marchi 2020-05-22 18:22 ` Chris Nicol 2020-05-22 18:51 ` Simon Marchi 2020-05-22 19:35 ` Chris Nicol 2020-05-23 17:40 ` Martin Simmons 2020-05-23 18:29 ` Chris Nicol 2020-05-23 22:17 ` Martin Simmons 2020-05-24 1:55 ` Chris Nicol 2020-05-24 14:05 ` Simon Marchi 2020-05-27 21:31 ` Martin Simmons [not found] ` <46566349-c023-6a75-7006-268aad4913c6@uleth.ca> 2020-05-28 10:57 ` Martin Simmons 2020-05-28 14:40 ` Chris Nicol 2020-05-28 17:30 ` Martin Simmons 2020-05-28 17:37 ` Chris Nicol 2020-05-23 16:29 ` gdb-9.1 Fails to build: "invalid cast to abstract class type" Joel Brobecker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).