linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Barris <rbarris@quicksilver.com>
To: flar@pants.nu (Brad Boyer), kaos@ocs.com.au (Keith Owens)
Cc: kaih@khms.westfalen.de (Kai Henningsen),
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.linuxppc.org
Subject: Re: PPC? (Was: Re: [RFC] /proc/ksyms change for IA64)
Date: Mon, 6 Aug 2001 15:43:47 -0700	[thread overview]
Message-ID: <v03010d03b794cd1af75a@[192.168.1.18]> (raw)
In-Reply-To: <20010806030520.153282B54A@marcus.pants.nu>
In-Reply-To: <29464.997040507@ocs3.ocs-net> from "Keith Owens" at Aug 06, 2001 05:41:47 AM

At 8:05 PM -0700 8/5/01, Brad Boyer wrote:
>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.

   The idea of a 'transition vector' to refer to a piece of code (and the
proper data-globals area to go with it) came part and parcel from the IBM
AIX runtime model, and had nothing to do with a MixedMode routine
descriptor as you describe above.  The two are separate beasts.

   A MixedMode descriptor helps classic MacOS handle all of the arguments,
stack layout, and return value issues when hopping from one processor
architecture to another at runtime.  Transition vectors are used far more
often, for any old inter-library call (for example, every app call to the
OS, even when both caller and callee are PPC native).


--
Rob Barris       Quicksilver Software Inc.      rbarris@quicksilver.com



  parent reply	other threads:[~2001-08-06 22:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-02  3:22 [RFC] /proc/ksyms change for IA64 Keith Owens
2001-08-05  5:44 ` Rusty Russell
2001-08-05  7:16   ` Keith Owens
2001-08-05 14:02     ` Rusty Russell
2001-08-05 14:51       ` Keith Owens
2001-08-05  9:29 ` PPC? (Was: Re: [RFC] /proc/ksyms change for IA64) Kai Henningsen
2001-08-05 19:41   ` Keith Owens
2001-08-05 20:26     ` Peter A. Castro
2001-08-06  3:05     ` Brad Boyer
2001-08-06 22:43     ` Rob Barris [this message]
2001-08-07  3:47   ` Anton Blanchard
2001-08-19  1:27 ` [RFC] /proc/ksyms change for IA64 Richard Henderson
2001-08-21  6:53   ` Keith Owens
2001-08-21 17:47     ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='v03010d03b794cd1af75a@[192.168.1.18]' \
    --to=rbarris@quicksilver.com \
    --cc=flar@pants.nu \
    --cc=kaih@khms.westfalen.de \
    --cc=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).