* 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-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
* 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
* 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
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).