From: Keith Owens <kaos@ocs.com.au>
To: kaih@khms.westfalen.de (Kai Henningsen)
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.linuxppc.org
Subject: Re: PPC? (Was: Re: [RFC] /proc/ksyms change for IA64)
Date: Mon, 06 Aug 2001 05:41:47 +1000 [thread overview]
Message-ID: <29464.997040507@ocs3.ocs-net> (raw)
In-Reply-To: Your message of "05 Aug 2001 11:29:00 +0200." <86HgALWHw-B@khms.westfalen.de>
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?
next prev parent reply other threads:[~2001-08-05 19:41 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 [this message]
2001-08-05 20:26 ` Peter A. Castro
2001-08-06 3:05 ` Brad Boyer
2001-08-06 22:43 ` Rob Barris
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=29464.997040507@ocs3.ocs-net \
--to=kaos@ocs.com.au \
--cc=kaih@khms.westfalen.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.