linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: Scott Wood <scottwood@freescale.com>, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
Date: Sat, 03 May 2008 09:23:04 +1000	[thread overview]
Message-ID: <1209770584.26383.8.camel@pasglop> (raw)
In-Reply-To: <BFB7B7A0-6EA9-467D-B23E-B0D46EF6BA54@kernel.crashing.org>


On Fri, 2008-05-02 at 16:34 -0500, Kumar Gala wrote:
> On May 2, 2008, at 12:34 PM, Segher Boessenkool wrote:
> 
> >>> <brokenrecord>
> >>> Why don't we just link with libgcc?
> >>> </brokenrecord>
> >>
> >> Its something of a PITA to do that in the kernel at this point  
> >> since we've duplicated libgcc functionality in it.  I'm sure there  
> >> are some historical reasons this wasn't done to start with.
> >
> > That's the same as saying that it would be a nice cleanup to remove  
> > all
> > that duplicated code now...
> 
> We'll hopefully this thread might spark either an explanation for why  
> we aren't just linking libgcc in a statement that says we should and  
> we can remove the code that implements libgcc functionality.
> 
> How would libgcc linking intermix with modules?  Would we have to  
> EXPORT_SYMBOL() all functions that libgcc implements?  I'm guessing  
> that's varies w/different gcc versions.

The historical reason for not linking with libgcc was around the lines
of "we want to catch when people do stupid things like 64 bits divides
in the kernel".

Nowadays, this is mostly moot and it's accepted that things might want
to do such operations here or there.

I personally don't see any problem with a patch that would make us link
with libgcc and get rid of the hacks.

Ben.

  parent reply	other threads:[~2008-05-02 23:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02 14:21 [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os Kumar Gala
2008-05-02 15:07 ` Scott Wood
2008-05-02 15:26   ` Kumar Gala
2008-05-02 17:34     ` Segher Boessenkool
2008-05-02 21:34       ` Kumar Gala
2008-05-02 21:40         ` Scott Wood
2008-05-02 21:42         ` David Miller
2008-05-02 21:45           ` Scott Wood
2008-05-02 22:04             ` David Miller
2008-05-02 22:16               ` Scott Wood
2008-05-02 22:30                 ` David Miller
2008-05-02 22:38                   ` Scott Wood
2008-05-02 22:39                     ` David Miller
2008-05-03  0:15               ` Segher Boessenkool
2008-05-02 23:24           ` Benjamin Herrenschmidt
2008-05-02 23:23         ` Benjamin Herrenschmidt [this message]
2008-05-08  6:26         ` Paul Mackerras
2008-05-02 17:33 ` Segher Boessenkool
2008-05-02 21:31   ` Kumar Gala

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=1209770584.26383.8.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=galak@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).