All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tom 'spot' Callaway" <tcallawa@redhat.com>
To: sparclinux@vger.kernel.org
Subject: Re: div, udiv, mul, umul, rem, urem broken again?!?
Date: Thu, 06 Oct 2005 13:21:20 +0000	[thread overview]
Message-ID: <1128604880.2140.123.camel@localhost.localdomain> (raw)
In-Reply-To: <1128550254.2140.103.camel@localhost.localdomain>

On Wed, 2005-10-05 at 17:24 -0700, David S. Miller wrote:
> From: "Tom 'spot' Callaway" <tcallawa@redhat.com>
> Date: Wed, 05 Oct 2005 17:10:54 -0500
> 
> > 7caaeabb17758295edff9703c18a840073c5b8f4
> 
> This change should cause us to lookup ".[a-z]*" symbols
> as "_[A-Z]*", as per the change made in handle_modversions()
> in scripts/mod/modpost.c
> 
> So when a module references ".udiv" that symbol reference
> should get rewritten to "_Udiv" and that latter symbol is
> what we actually export from the kernel.
> 
> As best as I can tell, what is needed is similar logic in
> depmod.  Ie. something like:
> 
> + 			if (symname[0] = '.') {
> + 				char *munged = strdup(symname);
> + 				munged[0] = '_';
> + 				munged[1] = toupper(munged[1]);
> + 				symname = munged;
> + 			}
> 
> I see you just hardcoded the various ".*" symbol names Sparc
> uses in your patch.

My concern was the comment around the existing routine in the depmod
code:

/* For our purposes, .foo matches foo.  PPC64 needs this. */
        if (name[0] = '.')
                name++;

If PPC64 still needs this, we can't just munge to the _<upper> condition
universally, we still need some mechanism of identifying whether we want
the PPC64 behavior for dot symbols or the sparc32 behavior for dot
symbols. By hardcoding the six sparc specific symbols, and changing them
first, we ensure that the PPC64 case still works.

I can shorten it a little bit by doing:

        /* Handle the wacky sparc cases */
        if (strcmp(name, ".div") = 0) || (strcmp(name, ".udiv") = 0)
|| (strcmp(name, ".mul") = 0)
           (strcmp(name, ".umul") = 0) || (strcmp(name, ".rem") = 0)
|| (strcmp(name, ".urem") = 0) {
                char *munged = strdup(name);
                munged[0] = '_';
                toupper(munged[1]);
                name = munged;
        }

But we'd still have to hardcode the names.

Of course, all of this is moot if the PPC64 is munging their dot symbols
in the same way.

~spot
-- 
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!


  parent reply	other threads:[~2005-10-06 13:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-05 22:10 div, udiv, mul, umul, rem, urem broken again?!? Tom 'spot' Callaway
2005-10-05 22:17 ` Tom 'spot' Callaway
2005-10-06  0:24 ` David S. Miller
2005-10-06 13:21 ` Tom 'spot' Callaway [this message]
2005-10-10 10:20 ` Rusty Russell
2005-10-10 14:35 ` Tom 'spot' Callaway
2005-10-10 18:22 ` David S. Miller
2005-10-11 10:03 ` Rusty Russell
2005-11-06  0:40 ` David S. Miller
2005-11-06  4:13 ` Tom 'spot' Callaway
2005-11-06  6:27 ` Rusty Russell
2005-11-06 20:56 ` David S. Miller
2005-11-06 20:58 ` David S. Miller
2006-02-08 20:25 ` Martin Habets
2006-02-08 20:51 ` Tom 'spot' Callaway
2006-02-08 20:56 ` Al Viro
2006-02-09  1:29 ` Rusty Russell

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=1128604880.2140.123.camel@localhost.localdomain \
    --to=tcallawa@redhat.com \
    --cc=sparclinux@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 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.