From: Helge Deller <deller@gmx.de>
To: Carlos O'Donell <carlos@systemhalted.org>
Cc: Frans Pop <elendil@planet.nl>,
539378@bugs.debian.org,
Debian HPPA Port List <debian-hppa@lists.debian.org>,
linux-parisc <linux-parisc@vger.kernel.org>,
Randolph Chung <randolph@tausq.org>,
Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Re: Bug#539378: [hppa]: fails to load nfs module: Global Offset Table overflow
Date: Fri, 31 Jul 2009 23:08:35 +0200 [thread overview]
Message-ID: <4A735D53.6060803@gmx.de> (raw)
In-Reply-To: <119aab440907311149j3e17466fy3782b86399142141@mail.gmail.com>
On 07/31/2009 08:49 PM, Carlos O'Donell wrote:
> [...]
> However, on 64-bit the long format of ldd has a 16-bit signed
> immediate offset (0xffff), meaning it can reach +0x7fff e.g. 4095 GOT
> slots.
>
> Do you have the time to test something out?
>
> * Make this conditional on 32-bit vs. 64-bit and allow for 4095 GOT
> entries on 64-bit.
> * Fix ELF_GOT_STUB for the 64-bit case. It needs to reassemble a
> 16-bit offset, the current code is IMO incorrect. i.e. it should be "&
> 0x7fff", and use a new reassemble_16 see the PA 2.0 book definition of
> ldd.
> * Build kernel.
> * Test loading NFS moudle.
Carlos, thanks a lot for those explanations (and keep up your work with NPTL :-)).
I'll know what you mean, and if it works it's a good idea.
I'll try to come up with a patch.
A few notes:
- the GOT table is only used for 64bit anyway, so no need to differentiate for 32/64bits
- Another possibility could be to sort the tables, so to reduce the number of needed entries.
Helge
prev parent reply other threads:[~2009-07-31 21:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090731091729.1105.20608.reportbug@aragorn.fjphome.nl>
2009-07-31 18:49 ` Bug#539378: [hppa]: fails to load nfs module: Global Offset Table overflow Carlos O'Donell
2009-07-31 19:03 ` Bug#539378: [hppa]: fails to load nfs module: Global Offset Table John David Anglin
2009-07-31 21:09 ` Helge Deller
2009-07-31 21:13 ` Carlos O'Donell
2009-07-31 21:14 ` Carlos O'Donell
2009-07-31 21:26 ` John David Anglin
2009-07-31 22:00 ` Carlos O'Donell
2009-07-31 23:38 ` Kyle McMartin
2009-07-31 23:45 ` Helge Deller
2009-07-31 0:37 ` John David Anglin
2009-07-31 1:16 ` John David Anglin
2009-08-01 1:51 ` Carlos O'Donell
2009-08-01 13:53 ` John David Anglin
2009-08-01 19:07 ` John David Anglin
2009-08-01 20:02 ` Carlos O'Donell
2009-08-01 21:17 ` Frans Pop
2009-08-01 8:08 ` Frans Pop
2009-08-01 1:49 ` Carlos O'Donell
2009-07-31 21:08 ` Helge Deller [this message]
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=4A735D53.6060803@gmx.de \
--to=deller@gmx.de \
--cc=539378@bugs.debian.org \
--cc=carlos@systemhalted.org \
--cc=debian-hppa@lists.debian.org \
--cc=elendil@planet.nl \
--cc=linux-parisc@vger.kernel.org \
--cc=randolph@tausq.org \
--cc=submit@bugs.debian.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.