Re: [rfc] PowerPC ABI detection and overrides

[Daniel Jacobowitz <drow@false.org>]

On Mon, Oct 29, 2007 at 07:59:00PM +0100, Ulrich Weigand wrote:
> 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.

Ignoring abfd is deliberate; we should be able to construct the same
arch with or without a BFD.  But ignoring things derived from abfd is
a bug indeed.  The MIPS target stashes ELF flags in its tdep structure
for this reason.  PowerPC may not need that heavyweight check, but it
does need some other things, e.g., sysv_abi.  Actually that's the only
one that I see that ought to be checked.  Maybe that will fix the bug?

-- 
Daniel Jacobowitz
CodeSourcery