All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: "Mark Huang" <mhuang@broadcom.com>
Cc: "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>
Subject: Re: DBE table ordering
Date: Thu, 18 Apr 2002 16:51:40 +1000	[thread overview]
Message-ID: <314.1019112700@ocs3.intra.ocs.com.au> (raw)
In-Reply-To: Your message of "17 Apr 2002 23:39:16 MST." <1019111956.2095.66.camel@mathom>

On 17 Apr 2002 23:39:16 -0700, 
"Mark Huang" <mhuang@broadcom.com> wrote:
>From the objdump output, it looks like the exception table is in order
>at link time, but the DBE table is definitely out of order. What seems
>to be throwing it off is the dummy call to get_dbe() in traps.c. After
>sprinkling a few more calls to get_dbe() around the kernel and seeing
>what happens during link, it looks like any call to get_dbe() inside an
>__init section (or probably any explicitly located section) will throw
>off the ordering of the table. 

That is what I expected.  Various tables are built up from special
sections in each object.  The linker is correctly appending those
sections to the final table in vmlinux.  The use of multiple text
sections (init, exit, the rest) means that entries in a table for each
object are not necessarily in order, breaking the assumption that the
overall table is in order.

This is a more general problem than mips dbe, other kernel tables and
other architectures will have the same problem.  I will do a general
patch against 2.5.8 to sort these tables at init time, and backport the
general fix to 2.4.19 later.  In the meantime your patch will bypass
the problem for mips dbe.

WARNING: multiple messages have this Message-ID (diff)
From: Keith Owens <kaos@ocs.com.au>
To: Mark Huang <mhuang@broadcom.com>
Cc: "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>
Subject: Re: DBE table ordering
Date: Thu, 18 Apr 2002 16:51:40 +1000	[thread overview]
Message-ID: <314.1019112700@ocs3.intra.ocs.com.au> (raw)
Message-ID: <20020418065140.r3wwbjhiU8uHLTyG7s5L4G-e8odZH4d-k5902cDgAnE@z> (raw)
In-Reply-To: Your message of "17 Apr 2002 23:39:16 MST." <1019111956.2095.66.camel@mathom>

On 17 Apr 2002 23:39:16 -0700, 
"Mark Huang" <mhuang@broadcom.com> wrote:
From the objdump output, it looks like the exception table is in order
>at link time, but the DBE table is definitely out of order. What seems
>to be throwing it off is the dummy call to get_dbe() in traps.c. After
>sprinkling a few more calls to get_dbe() around the kernel and seeing
>what happens during link, it looks like any call to get_dbe() inside an
>__init section (or probably any explicitly located section) will throw
>off the ordering of the table. 

That is what I expected.  Various tables are built up from special
sections in each object.  The linker is correctly appending those
sections to the final table in vmlinux.  The use of multiple text
sections (init, exit, the rest) means that entries in a table for each
object are not necessarily in order, breaking the assumption that the
overall table is in order.

This is a more general problem than mips dbe, other kernel tables and
other architectures will have the same problem.  I will do a general
patch against 2.5.8 to sort these tables at init time, and backport the
general fix to 2.4.19 later.  In the meantime your patch will bypass
the problem for mips dbe.

  reply	other threads:[~2002-04-18  6:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-17 22:21 DBE table ordering Mark Huang
2002-04-18  3:55 ` Keith Owens
2002-04-18  6:39   ` Mark Huang
2002-04-18  6:39     ` Mark Huang
2002-04-18  6:51     ` Keith Owens [this message]
2002-04-18  6:51       ` Keith Owens
2002-04-18  9:37       ` Gleb O. Raiko
2002-04-18  9:49         ` Keith Owens
2002-04-18 12:03           ` Gleb O. Raiko
2002-04-18 17:59             ` Maciej W. Rozycki
2002-04-19  8:28               ` Gleb O. Raiko
2002-04-19 12:19                 ` Maciej W. Rozycki

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=314.1019112700@ocs3.intra.ocs.com.au \
    --to=kaos@ocs.com.au \
    --cc=linux-mips@oss.sgi.com \
    --cc=mhuang@broadcom.com \
    /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.