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

Chris Nicol nicolc@uleth.ca
Sat May 23 18:29:49 GMT 2020


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





More information about the Gdb mailing list