Linux PARISC architecture development
 help / color / mirror / Atom feed
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;

  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