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

[Martin Simmons <qqxnjvamvxwx@dyxyl.com>]

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