From: akpm@linux-foundation•org (Andrew Morton)
To: linux-arm-kernel@lists•infradead.org
Subject: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'
Date: Wed, 12 Aug 2015 20:28:08 -0700 [thread overview]
Message-ID: <20150812202808.abe0c080.akpm@linux-foundation.org> (raw)
In-Reply-To: <55CBC6C6.3090306@kernel.org>
On Wed, 12 Aug 2015 15:20:54 -0700 Andy Lutomirski <luto@kernel•org> wrote:
> On 08/12/2015 08:49 AM, Linus Torvalds wrote:
> > On Tue, Aug 11, 2015 at 11:24 PM, Christoph Hellwig <hch@infradead•org> wrote:
> >>
> >> Maybe it's time to rely on gcc to handle 64 bit divisions now?
> >
> > Ugh. gcc still does a pretty horrible job at it. While gcc knows that
> > a widening 32x32->64 multiplication can be simplified, it doesn't do
> > the same thing for a 64/32->64 division, and always calls __udivdi3
> > for it.
> >
> > Now, __udivdi3 does avoid the general nasty case by then testing the
> > upper 32 bits of the divisor against zero, so it's not entirely
> > disastrous. It's just ugly.
> >
> > But perhaps more importantly, I'm not at all sure libgcc is
> > kernel-safe. In particular, I'm not at all sure it *remains*
> > kernel-safe. Just as an example: can you guarantee that libgcc doesn't
> > implement integer division on some architecture by using the FP
> > hardware?
> >
> > There's been a few cases where not having libgcc saved us headaches. I
> > forget the exact details, but it was something like several years ago
> > that we had gcc start to generate some insane crap exception handling
> > for C code generation, and the fact that we didn't include libgcc was
> > what made us catch it because of the resulting link error.
> >
> > libgcc just isn't reliable in kernel space. I'm not opposed to some
> > random architecture using it (arch/tile does include "-lgcc" for
> > example), but I _do_ object to the notion that we say "let's use
> > libgcc in general".
> >
> > So no. I do not believe that the occasional pain of a few people who
> > do 64-bit divides incorrectly is a good enough argument to start using
> > libgcc.
> >
>
> Does your objection still apply if we supplied our own implementations
> of a handful of libgcc helpers?
It's not just a matter of "how fast is the divide". The 32-bit build
error is supposed to prompt people to ask "did I really need to use 64
bits".
That *used* to work. A bit. But nowadays the errors are detected so
late that the fix (often by someone other than the original developer)
is to just slap a do_div() in there.
And as the build error no longer appears to be having the desired
effect, I too have been wondering if it's time to just give up and
implement __udivdi and friends.
Or maybe there's a way of breaking 64-bit builds instead ;)
next prev parent reply other threads:[~2015-08-13 3:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5579B804.9050707@skylable.com>
[not found] ` <20150612122108.GB60661@bfoster.bfoster>
[not found] ` <557AD4D4.3010901@skylable.com>
[not found] ` <20150612225209.GA20262@dastard>
2015-08-12 0:56 ` PROBLEM: XFS on ARM corruption 'Structure needs cleaning' katsuki.uwatoko at toshiba.co.jp
2015-08-12 3:14 ` Dave Chinner
2015-08-12 6:19 ` katsuki.uwatoko at toshiba.co.jp
2015-08-12 6:24 ` enabling libgcc for 64-bit divisions, was " Christoph Hellwig
2015-08-12 15:49 ` Linus Torvalds
2015-08-12 22:20 ` Andy Lutomirski
2015-08-12 22:36 ` Linus Torvalds
2015-08-12 22:39 ` Andy Lutomirski
2015-08-13 3:28 ` Andrew Morton [this message]
2015-10-08 15:50 ` Pavel Machek
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=20150812202808.abe0c080.akpm@linux-foundation.org \
--to=akpm@linux-foundation$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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