gdb-9.1 Fails to build: "invalid cast to abstract class type"

gdb-9.1 Fails to build: "invalid cast to abstract class type"

[Chris Nicol]

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.
-- 
______________________________________________________________________

Re: gdb-9.1 Fails to build: "invalid cast to abstract class type"

[Simon Marchi]

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

Re: gdb-9.1 Fails to build: "invalid cast to abstract class type"

[Chris Nicol]

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
>>
> 
> 
> 

gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Chris Nicol]

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.

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Simon Marchi]

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

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Chris Nicol]

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

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Simon Marchi]

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

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Chris Nicol]

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
> 

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Martin Simmons]

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
> > 
> 
> 
> 
> 
> 

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Chris Nicol]

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
>>>
>>
>>
>>
>>
>>

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Martin Simmons]

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
> >>>
> >>
> >>
> >>
> >>
> >>
> 
> 
> 
> 

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Chris Nicol]

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

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Simon Marchi]

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

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Martin Simmons]

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
> 

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Martin Simmons]

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
> > 

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Chris Nicol]

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

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Martin Simmons]

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
> 

Re: gdb 8.3: "handler for the OSI ABI "FreeBSD" is not built into this configuration"

[Chris Nicol]

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
> 

Re: gdb-9.1 Fails to build: "invalid cast to abstract class type"

[Joel Brobecker]

> 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