From: Helge Deller <deller@gmx.de>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>,
linux-parisc@vger.kernel.org, Kyle McMartin <kyle@mcmartin.ca>
Subject: Re: Out of order unwind entry warning
Date: Sat, 7 Nov 2009 00:07:42 +0100 [thread overview]
Message-ID: <20091106230742.GA16061@p100.box> (raw)
In-Reply-To: <20091104005737.0E4674FB2@hiauly1.hia.nrc.ca>
Hi Dave,
* John David Anglin <dave@hiauly1.hia.nrc.ca>:
> > >> Relocation section '.rela.PARISC.unwind' at offset 0x9b8 contains 6 entries:
> > >> Offset Info Type Sym.Value Sym. Name + Addend
> > >> 00000000 00000231 R_PARISC_SEGREL32 00000000 .exit.text + 0
> > >> 00000004 00000231 R_PARISC_SEGREL32 00000000 .exit.text + 2c
> > >> 00000010 00000331 R_PARISC_SEGREL32 00000000 .init.text + 0
> > >> 00000014 00000331 R_PARISC_SEGREL32 00000000 .init.text + 44
> > >> 00000020 00000431 R_PARISC_SEGREL32 00000000 .text.crc32c + 0
> > >> 00000024 00000431 R_PARISC_SEGREL32 00000000 .text.crc32c + 6c
> > >
> > > That's exactly what I expected. There's no overlap. The module
> > > loader needs to sort the unwind entries after doing the relocations.
You were right here.
> > It's already sorting the entries,
and I was to some degree wrong :-)
The parisc module loader as written by Randolph was sorting the
unwind entries. But I submitted a wrong patch which replaced the
hand-written sort() by the kernel provided sort() function:
http://patchwork.kernel.org/patch/56528/
Due to a bug in the patch a wrong amount of unwind entries were
calculated and as such the sort() function didn't sorted all unwind entries.
Below is an updated patch. With this one, all your binutils changes
work nicely with 32- and 64-bit kernels and modules.
Kyle, I see you applied my original patch into your "next" tree already:
http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commit;h=b8d46862d910c3be7c28c627204da968c174aa9a
Do you want me to send you a new patch against your "next" tree instead?
> > If we change this, don't we require a binutils update then at the same time from the users?
>
> Don't think fixing the offsets requires a binutils update. However, the
> change to using section offsets may have made the problem worse. The binutils
> update only corrected the issue with overloaded symbols.
Yes, a binutils update will just fix user's "out-of-order-unwind-entry"
warnings.
Thanks!
Helge
PATCH: parisc: use sort() instead of home-made implementation (v2)
Signed-off-by: Helge Deller <deller@gmx.de>
diff --git a/arch/parisc/kernel/unwind.c b/arch/parisc/kernel/unwind.c
index 69dad5a..9dbefa8 100644
--- a/arch/parisc/kernel/unwind.c
+++ b/arch/parisc/kernel/unwind.c
@@ -13,6 +13,7 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/kallsyms.h>
+#include <linux/sort.h>
#include <asm/uaccess.h>
#include <asm/assembly.h>
@@ -115,24 +116,18 @@ unwind_table_init(struct unwind_table *table, const char *name,
}
}
+static int cmp_unwind_table_entry(const void *a, const void *b)
+{
+ return ((const struct unwind_table_entry *)a)->region_start
+ - ((const struct unwind_table_entry *)b)->region_start;
+}
+
static void
unwind_table_sort(struct unwind_table_entry *start,
struct unwind_table_entry *finish)
{
- struct unwind_table_entry el, *p, *q;
next prev parent reply other threads:[~2009-11-06 23:07 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-26 22:21 Out of order unwind entry warning Helge Deller
2009-10-26 23:41 ` Kyle McMartin
2009-10-27 1:50 ` Randolph Chung
2009-10-27 2:24 ` Kyle McMartin
2009-10-27 23:19 ` John David Anglin
2009-10-28 21:42 ` Helge Deller
2009-10-28 22:00 ` Helge Deller
2009-10-28 23:10 ` John David Anglin
2009-10-29 20:51 ` Helge Deller
2009-10-29 13:20 ` Carlos O'Donell
2009-10-28 22:18 ` John David Anglin
2009-10-28 22:43 ` Helge Deller
2009-10-28 22:59 ` Helge Deller
2009-10-29 2:11 ` John David Anglin
2009-10-29 16:38 ` John David Anglin
2009-10-29 19:16 ` John David Anglin
2009-10-29 20:46 ` Helge Deller
2009-10-29 21:07 ` John David Anglin
2009-10-29 22:22 ` Helge Deller
2009-10-29 23:35 ` John David Anglin
2009-10-30 22:47 ` Helge Deller
2009-10-31 0:41 ` John David Anglin
2009-10-31 2:19 ` John David Anglin
2009-10-31 7:39 ` Helge Deller
2009-11-01 23:16 ` John David Anglin
2009-11-02 1:40 ` John David Anglin
2009-11-02 2:34 ` John David Anglin
2009-11-02 21:02 ` Helge Deller
2009-11-02 21:50 ` John David Anglin
2009-11-02 22:20 ` Helge Deller
2009-11-02 22:31 ` James Bottomley
2009-11-02 22:43 ` Helge Deller
2009-11-02 22:52 ` Helge Deller
2009-11-02 23:23 ` John David Anglin
2009-11-03 21:10 ` Helge Deller
2009-11-03 21:36 ` John David Anglin
2009-11-03 21:43 ` Helge Deller
2009-11-03 21:54 ` John David Anglin
2009-11-03 22:04 ` Helge Deller
2009-11-04 0:57 ` John David Anglin
2009-11-06 23:07 ` Helge Deller [this message]
2009-11-07 20:11 ` Kyle McMartin
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=20091106230742.GA16061@p100.box \
--to=deller@gmx.de \
--cc=dave@hiauly1.hia.nrc.ca \
--cc=kyle@mcmartin.ca \
--cc=linux-parisc@vger.kernel.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