Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1205607 > unrolled thread

enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM  corruption 'Structure needs cleaning' Christoph Hellwig <hch@infradead.org> - 2015-08-12 08:30 +0200
    Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM  corruption 'Structure needs cleaning' Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-12 17:50 +0200
      Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM  corruption 'Structure needs cleaning' Andy Lutomirski <luto@kernel.org> - 2015-08-13 00:30 +0200
        Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM  corruption 'Structure needs cleaning' Andy Lutomirski <luto@amacapital.net> - 2015-08-13 00:40 +0200
        Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM  corruption 'Structure needs cleaning' Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 00:40 +0200
        Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on  ARM corruption 'Structure needs cleaning' Andrew Morton <akpm@linux-foundation.org> - 2015-08-13 05:30 +0200

#1205607 — enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'

On Wed, Aug 12, 2015 at 12:56:25AM +0000, katsuki.uwatoko@toshiba.co.jp wrote:
> On Sat, 13 Jun 2015 08:52:09 +1000, Dave Chinner wrote:
> 
> > Yup, that's looking like a toolchain bug. Thread about arm directory
> > read corruption:
> 
> I think that this is not a toolchain bug, this is related to 
> Subject: [PATCH v2 1/1] ARM : missing corrupted reg in __do_div_asm
> http://www.spinics.net/lists/arm-kernel/msg426684.html

Maybe it's time to rely on gcc to handle 64 bit divisions now?

I've been pretty annoyed at the amount of 32-bit architecture build
failures due to the lack of support for native 64-bit divisions, and
the ugly do_div hackery to work around it.

We're living in a world where we are using a lot of 64-bit CPUs and
people optimize for them, so it might be a good time to start relying
on the compiler to get these right on older CPUs.

How bad is gcc's code for 64-bit divisions on arm and x86 these days?
Is there still a good case for offloading work the compiler should be
doing on the programmer?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1206219

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.

                 Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1206394

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?

--Andy

>                   Linus
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1206395

On Wed, Aug 12, 2015 at 3:36 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Aug 12, 2015 at 3:20 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>
>> Does your objection still apply if we supplied our own implementations of a
>> handful of libgcc helpers?
>
> We already do that.
>
> Several architectures actually implement _udivdi3.
>
> However, do_div() is actually the much simpler/better interface.
>
> I don't think we have a single case in the kernel where we really want
> the full 64/64 division, and the 64/32->64 case really is
> fundamentally simpler.
>
> This whole "do_div is so complicated" thing is just BS.
>
> The thing that triggered Christoph to ask was a bug in the
> implementation of that *simpler*  interface. What makes you think that
> making people implement _udivdi3 would magically avoid all such bugs?
>

Nothing.

We could ask gcc to fix this, I suppose (add __udiv_64_over_32 or whatever).

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1206397

On Wed, Aug 12, 2015 at 3:20 PM, Andy Lutomirski <luto@kernel.org> wrote:
>
> Does your objection still apply if we supplied our own implementations of a
> handful of libgcc helpers?

We already do that.

Several architectures actually implement _udivdi3.

However, do_div() is actually the much simpler/better interface.

I don't think we have a single case in the kernel where we really want
the full 64/64 division, and the 64/32->64 case really is
fundamentally simpler.

This whole "do_div is so complicated" thing is just BS.

The thing that triggered Christoph to ask was a bug in the
implementation of that *simpler*  interface. What makes you think that
making people implement _udivdi3 would magically avoid all such bugs?

                Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1206487 — Re: enabling libgcc for 64-bit divisions, was Re: PROBLEM: XFS on ARM corruption 'Structure needs cleaning'

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 ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web