This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] PowerPC ABI detection and overrides


Daniel Jacobowitz wrote:

> > Hmmm, I would have hoped we could get away from directly refering
> > to the BFD in the gdbarch_init routine ...   It would be nicer to
> > more strictly distinguish between detecting ABI properties from
> > the BFD (in the *sniffer*), and installing an gdbarch handler 
> > supporting a particular set of ABI properties (in the gdbarch_init
> > routine).
> > 
> > This would allow to request a specific gdbarch in the situation
> > where you know exactly which ABI properties you need, but don't
> > have any BFD handy ...
> 
> Can you give me an example of when you want to do that?  In general
> I've been moving away from it - there's too much extra bookkeeping
> that the BFD does for us.

The situation came up in the context of the multi-architecture
Cell debugger, where you have to switch between SPU and PPC gdbarchs.
Now, in most case, you'll have an appropriate BFD available anyway,
but in some cases you don't: e.g. when debugging a "stand-alone"
SPU executable, the only BFD you have at start-up is SPU, but the
inferior process is actually still a PPC, and the underlying 
infrastucture has in fact loaded PPC-side ld.so and libraries.

In this situation, I want to get at those by starting from the
PT_DYNAMIC header retrieved from the AT_PHDR AUXV entries, and
finding my way to the ld.so structures.  But to even properly
access the target, I need to switch to a PPC gdbarch even before
I have any PPC BFD available.


Thinking about the problem I had at the time, maybe the real issue
is that those features detected from the BFD are not considered
as distinuishing factors when deciding whether to set up a new
gdbarch or return a cached one:

  /* Find a candidate among extant architectures.  */
  for (arches = gdbarch_list_lookup_by_info (arches, &info);
       arches != NULL;
       arches = gdbarch_list_lookup_by_info (arches->next, &info))
    {
      /* Word size in the various PowerPC bfd_arch_info structs isn't
         meaningful, because 64-bit CPUs can run in 32-bit mode.  So, perform
         separate word size check.  */
      tdep = gdbarch_tdep (arches->gdbarch);
      if (tdep && tdep->wordsize == wordsize)
        {
          if (tdesc_data != NULL)
            tdesc_data_cleanup (tdesc_data);
          return arches->gdbarch;
        }
    }


Note that gdbarch_list_lookup_by_info ignores the info.abfd field.
This means that if you first looked up any PPC gdbarch without specifying
a BFD, and later on you look up a PPC gdbarch with BFD, you'll get that
first gdbarch returned from the cache, even though it doesn't actually
fit the current properties.


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]