Re: PPC? (Was: Re: [RFC] /proc/ksyms change for IA64)
Brad Boyer (flar@pants.nu)
Sun, 5 Aug 2001 20:05:20 -0700 (PDT)
Keith Owens wrote:
> On 05 Aug 2001 11:29:00 +0200,
> kaih@khms.westfalen.de (Kai Henningsen) wrote:
> >kaos@ocs.com.au (Keith Owens) wrote on 02.08.01 in <22165.996722560@kao2.melbourne.sgi.com>:
> >
> >> The IA64 use of descriptors for function pointers has bitten ksymoops.
> >> For those not familiar with IA64, &func points to a descriptor
> >> containing { &code, &data_context }.
> >
> >That sounds suspiciously like what I remember from PPC. How is this solved
> >on the PPC side?
>
> Best guess, without access to a PPC box, is that it is not solved. Any
> arch where function pointers go via a descriptor will have this
> problem.
>
> PPC users, does /proc/ksyms contain the address of the function code or
> the address of a descriptor which points to the code? It is easy to
> tell, if function entries in /proc/ksyms are close together (8-128
> bytes apart) and do not match the addresses in System.map then PPC has
> the same problem as IA64. If this is true, what is the layout of a PPC
> function descriptor so I can handle that case as well?
This is what the MacOS does on ppc, but it's specific to the MacOS, and
is part of the way the MacOS seamlessly integrates 68k code and ppc code
so that they didn't have to have both 68k and ppc versions of all the
system calls. This was basically a trick to pack in extra information
along with a function pointer to tell the Mixed Mode Manager if it needed
to run the 68k emulator and also how to setup the right context. I'm
pretty sure that Linux just does the normal address for function pointers
just like most other architectures.
Brad Boyer
flar@allandria.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/