Re: [PATCH][RFC] getting rid of stupid loop in BUG()
From: "H. Peter Anvin" <[EMAIL PROTECTED]> Date: Wed, 25 Jul 2007 13:37:00 -0700 > Another useful extension was a variant of __builtin_trap() which would > create a dummy ELF relocation for the trapping instruction with a target. That would be very useful. Another idea that has been tossed around is to build with dwarf2 debugging, scan a pre-linked kernel image for conditional trap instructions, and use the dwarf2 info to reconstruct the file and line number information into the table of BUG entries. Then perform the final link and strip the dwarf2 debugging info out. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Chuck Ebbert wrote: > On 07/25/2007 01:41 PM, Jeremy Fitzhardinge wrote: >> I reported it as a gcc bug, but they refused to hear of it. Details at >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305 >> > > Wow. > > I especially like "You should plan a better way. " FWIW, at Transmeta we had a local extension to gcc called "__builtin_not_reached()" which we used to tell gcc that an assembly statement would terminate the control flow. Another useful extension was a variant of __builtin_trap() which would create a dummy ELF relocation for the trapping instruction with a target. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On 07/25/2007 01:41 PM, Jeremy Fitzhardinge wrote: > > I reported it as a gcc bug, but they refused to hear of it. Details at > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305 > Wow. I especially like "You should plan a better way. " - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
David Miller wrote: > > Another issue is that if you have a conditional trap instruction on > your cpu, and you try the __label__ trick, GCC no longer converts: > > BUG_ON(test) > > into just a: > > set condition codes; > conditional_trap; > > sequence because the "stuff" inside the basic block is something > more than just the __builtin_trap(). > > The holy grail would be being able to get the perfect conditional > trap sequence, plus the annotations in a seperate section. I think that would require a custom gcc builtin, which we might be able to ask the gcc folks for... -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
From: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Date: Wed, 25 Jul 2007 10:36:49 -0700 > I tried that, but there's still no way of getting a pointer to the ud2a > instruction in there. gcc just generates garbage if you try to use use > the & syntax on a label which isn't (potentially) the target of a > goto (it just gets placed somewhere random). > > But there's a bigger problem than that. If the BUG is in code which can > be replicated (ie inlined or unrolled), then it would also require > replicating the static variable... Another issue is that if you have a conditional trap instruction on your cpu, and you try the __label__ trick, GCC no longer converts: BUG_ON(test) into just a: set condition codes; conditional_trap; sequence because the "stuff" inside the basic block is something more than just the __builtin_trap(). The holy grail would be being able to get the perfect conditional trap sequence, plus the annotations in a seperate section. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
From: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Date: Wed, 25 Jul 2007 10:00:20 -0700 > No, not any more. The file and line info is out of line, in a separate > section, indexed by the ud2a's eip. The main problem with > __builtin_trap is that there's no certain way to get the actual ud2a eip > (ie, paste an asm label onto it). Yes, I tried very hard to accomplish this myself, it would be wonderful if it could be made to work. I tried tricks using __label__ in inline asm, everything. It would be workable if condition codes could be passed into inline asm statements somehow, or the address of the builtin_trap() could be reliably obtained. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, 25 Jul 2007, Al Viro wrote:
>
> Umm... Actually, we might be able to do something like
> {
> l: __builtin_trap();
> static struct ... v __attribute__((section(...))) = { &, n, file };
No.
A C-level label is a pointer to a C-level construct.
The compiler may have reasons to put other instructions in between the
label and the final end result of the __builtin_trap. The above may work
for some trivial test-case, but in the end, the label and the __builtin
are *not* atomic, and the compiler may well end up having register spills
etc in there, or having CSE'd two traps, or any number of details meaning
that the label doesn't point to the exact ud2 instruction.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: > On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote: > >> We don't just do the "ud2" instruction - we also do the file and line >> number information after it. Which means that __builtin_trap() is useless. >> >> So we might as well keep the loop, since both are two-byte instructions >> that tell gcc that it will never continue. >> > > Actually, the worse problem is that gcc will happily merge these guys. > And that's a killer. > Merge __builtin_traps()? Ugh. But also, there's no real long-term guarantee that it will keep generating ud2a. The *only* mention of it in the manual is a discussion that it will emit a call to abort() on arches which don't otherwise support it. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote:
> On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
>
>> On Tue, 24 Jul 2007, David Miller wrote:
>>
>>> From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>>> Date: Tue, 24 Jul 2007 23:24:55 -0700
>>>
>>>
H. Peter Anvin wrote:
> How far back was __builtin_trap() supported?
>
I think its relatively recent, but it might be within our supported
compiler window.
>>> I'm pretty sure it is.
>>>
>> .. and I'm pretty sure it's immaterial.
>>
>> We don't just do the "ud2" instruction - we also do the file and line
>> number information after it. Which means that __builtin_trap() is useless.
>>
>> So we might as well keep the loop, since both are two-byte instructions
>> that tell gcc that it will never continue.
>>
>
> Umm... Actually, we might be able to do something like
> {
> l: __builtin_trap();
> static struct ... v __attribute__((section(...))) = { &, n, file };
> }
>
> except that it would need block-local labels and those are ugly (so's
> &&, while we are at it)...
>
I couldn't get it to work. It would be nice, because it would more or
less eliminate the need for asm in setting up BUGs - particularly the
nasty asm setting up the structure.
But it just doesn't work. The label & ends up pointing to is not
anywhere near the __builtin_trap instruction; I found it tended to point
to the start of the function prologue.
I reported it as a gcc bug, but they refused to hear of it. Details at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
J
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: > Who said that we need to populate that section from asm? Define > a static variable in that section inside a block; identifier is > not a problem, obviously. > > I'm not saying that it's not revolting, but it's not impossible. > I tried that, but there's still no way of getting a pointer to the ud2a instruction in there. gcc just generates garbage if you try to use use the & syntax on a label which isn't (potentially) the target of a goto (it just gets placed somewhere random). But there's a bigger problem than that. If the BUG is in code which can be replicated (ie inlined or unrolled), then it would also require replicating the static variable... J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote: > We don't just do the "ud2" instruction - we also do the file and line > number information after it. Which means that __builtin_trap() is useless. > > So we might as well keep the loop, since both are two-byte instructions > that tell gcc that it will never continue. Actually, the worse problem is that gcc will happily merge these guys. And that's a killer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro <[EMAIL PROTECTED]> wrote: > Where do you see passing && to assembly? More interesting question > is whether gcc believes it to be const... Passing labels like that to assembly didn't used to work, which is a pity as we could speed up things like get_user() if it could be made to. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote:
> On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
>>
>> On Tue, 24 Jul 2007, David Miller wrote:
>>> From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>>> Date: Tue, 24 Jul 2007 23:24:55 -0700
>>>
H. Peter Anvin wrote:
> How far back was __builtin_trap() supported?
I think its relatively recent, but it might be within our supported
compiler window.
>>> I'm pretty sure it is.
>> .. and I'm pretty sure it's immaterial.
>>
>> We don't just do the "ud2" instruction - we also do the file and line
>> number information after it. Which means that __builtin_trap() is useless.
>>
>> So we might as well keep the loop, since both are two-byte instructions
>> that tell gcc that it will never continue.
>
> Umm... Actually, we might be able to do something like
> {
> l: __builtin_trap();
> static struct ... v __attribute__((section(...))) = { &, n, file };
> }
>
> except that it would need block-local labels and those are ugly (so's
> &&, while we are at it)...
I thought gcc was buggy when it came to passing & to assembly.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, Jul 25, 2007 at 10:22:15AM -0700, H. Peter Anvin wrote:
> >> So we might as well keep the loop, since both are two-byte instructions
> >> that tell gcc that it will never continue.
> >
> > Umm... Actually, we might be able to do something like
> > {
> > l: __builtin_trap();
> > static struct ... v __attribute__((section(...))) = { &, n, file };
> > }
> >
> > except that it would need block-local labels and those are ugly (so's
> > &&, while we are at it)...
>
> I thought gcc was buggy when it came to passing & to assembly.
Where do you see passing && to assembly? More interesting question
is whether gcc believes it to be const...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, Jul 25, 2007 at 10:19:55AM -0700, Linus Torvalds wrote: > > > On Wed, 25 Jul 2007, Jeremy Fitzhardinge wrote: > > > > No, not any more. The file and line info is out of line, in a separate > > section, indexed by the ud2a's eip. > > That's irrelevant - the point is, we need to do the ud2 by hand, since we > need to control the code generation in order to associate the ud2 with the > proper file/linenr. > > > The main problem with __builtin_trap is that there's no certain way to > > get the actual ud2a eip (ie, paste an asm label onto it). > > Right. Which is why we need to do it as an inline asm. Who said that we need to populate that section from asm? Define a static variable in that section inside a block; identifier is not a problem, obviously. I'm not saying that it's not revolting, but it's not impossible. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
>
>
> On Tue, 24 Jul 2007, David Miller wrote:
> >
> > From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> > Date: Tue, 24 Jul 2007 23:24:55 -0700
> >
> > > H. Peter Anvin wrote:
> > > > How far back was __builtin_trap() supported?
> > >
> > > I think its relatively recent, but it might be within our supported
> > > compiler window.
> >
> > I'm pretty sure it is.
>
> .. and I'm pretty sure it's immaterial.
>
> We don't just do the "ud2" instruction - we also do the file and line
> number information after it. Which means that __builtin_trap() is useless.
>
> So we might as well keep the loop, since both are two-byte instructions
> that tell gcc that it will never continue.
Umm... Actually, we might be able to do something like
{
l: __builtin_trap();
static struct ... v __attribute__((section(...))) = { &, n, file };
}
except that it would need block-local labels and those are ugly (so's
&&, while we are at it)...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, 25 Jul 2007, Jeremy Fitzhardinge wrote: > > No, not any more. The file and line info is out of line, in a separate > section, indexed by the ud2a's eip. That's irrelevant - the point is, we need to do the ud2 by hand, since we need to control the code generation in order to associate the ud2 with the proper file/linenr. > The main problem with __builtin_trap is that there's no certain way to > get the actual ud2a eip (ie, paste an asm label onto it). Right. Which is why we need to do it as an inline asm. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Jeremy Fitzhardinge wrote: > Linus Torvalds wrote: >> .. and I'm pretty sure it's immaterial. >> >> We don't just do the "ud2" instruction - we also do the file and line >> number information after it. Which means that __builtin_trap() is useless. >> > > No, not any more. The file and line info is out of line, in a separate > section, indexed by the ud2a's eip. The main problem with > __builtin_trap is that there's no certain way to get the actual ud2a eip > (ie, paste an asm label onto it). > Same difference, then... -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Linus Torvalds wrote: > .. and I'm pretty sure it's immaterial. > > We don't just do the "ud2" instruction - we also do the file and line > number information after it. Which means that __builtin_trap() is useless. > No, not any more. The file and line info is out of line, in a separate section, indexed by the ud2a's eip. The main problem with __builtin_trap is that there's no certain way to get the actual ud2a eip (ie, paste an asm label onto it). J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Tue, 24 Jul 2007, David Miller wrote: > > From: Jeremy Fitzhardinge <[EMAIL PROTECTED]> > Date: Tue, 24 Jul 2007 23:24:55 -0700 > > > H. Peter Anvin wrote: > > > How far back was __builtin_trap() supported? > > > > I think its relatively recent, but it might be within our supported > > compiler window. > > I'm pretty sure it is. .. and I'm pretty sure it's immaterial. We don't just do the "ud2" instruction - we also do the file and line number information after it. Which means that __builtin_trap() is useless. So we might as well keep the loop, since both are two-byte instructions that tell gcc that it will never continue. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Tue, Jul 24, 2007 at 11:29:14PM -0700, David Miller wrote:
> From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> Date: Tue, 24 Jul 2007 23:24:55 -0700
>
> > H. Peter Anvin wrote:
> > > How far back was __builtin_trap() supported?
> >
> > I think its relatively recent, but it might be within our supported
> > compiler window.
>
> I'm pretty sure it is.
We had this in include/asm-s390/bug.h to avoid compile errors with gcc 3.2:
+#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 3)
+ __builtin_trap();
+#else
+ asm volatile(".long 0");
+#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
From: Jeremy Fitzhardinge <[EMAIL PROTECTED]> Date: Tue, 24 Jul 2007 23:24:55 -0700 > H. Peter Anvin wrote: > > How far back was __builtin_trap() supported? > > I think its relatively recent, but it might be within our supported > compiler window. I'm pretty sure it is. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
H. Peter Anvin wrote: > INT 6 is #UD, so the __builtin_trap() replaces the ud2a as well as the loop. > __builtin_trap() emits an actual ud2a; the effect is an int 6, of course. > How far back was __builtin_trap() supported? I think its relatively recent, but it might be within our supported compiler window. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
H. Peter Anvin wrote: INT 6 is #UD, so the __builtin_trap() replaces the ud2a as well as the loop. __builtin_trap() emits an actual ud2a; the effect is an int 6, of course. How far back was __builtin_trap() supported? I think its relatively recent, but it might be within our supported compiler window. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
From: Jeremy Fitzhardinge [EMAIL PROTECTED] Date: Tue, 24 Jul 2007 23:24:55 -0700 H. Peter Anvin wrote: How far back was __builtin_trap() supported? I think its relatively recent, but it might be within our supported compiler window. I'm pretty sure it is. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Tue, Jul 24, 2007 at 11:29:14PM -0700, David Miller wrote: From: Jeremy Fitzhardinge [EMAIL PROTECTED] Date: Tue, 24 Jul 2007 23:24:55 -0700 H. Peter Anvin wrote: How far back was __builtin_trap() supported? I think its relatively recent, but it might be within our supported compiler window. I'm pretty sure it is. We had this in include/asm-s390/bug.h to avoid compile errors with gcc 3.2: +#if __GNUC__ 3 || (__GNUC__ == 3 __GNUC_MINOR__ = 3) + __builtin_trap(); +#else + asm volatile(.long 0); +#endif - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Tue, 24 Jul 2007, David Miller wrote: From: Jeremy Fitzhardinge [EMAIL PROTECTED] Date: Tue, 24 Jul 2007 23:24:55 -0700 H. Peter Anvin wrote: How far back was __builtin_trap() supported? I think its relatively recent, but it might be within our supported compiler window. I'm pretty sure it is. .. and I'm pretty sure it's immaterial. We don't just do the ud2 instruction - we also do the file and line number information after it. Which means that __builtin_trap() is useless. So we might as well keep the loop, since both are two-byte instructions that tell gcc that it will never continue. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Linus Torvalds wrote: .. and I'm pretty sure it's immaterial. We don't just do the ud2 instruction - we also do the file and line number information after it. Which means that __builtin_trap() is useless. No, not any more. The file and line info is out of line, in a separate section, indexed by the ud2a's eip. The main problem with __builtin_trap is that there's no certain way to get the actual ud2a eip (ie, paste an asm label onto it). J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, 25 Jul 2007, Jeremy Fitzhardinge wrote: No, not any more. The file and line info is out of line, in a separate section, indexed by the ud2a's eip. That's irrelevant - the point is, we need to do the ud2 by hand, since we need to control the code generation in order to associate the ud2 with the proper file/linenr. The main problem with __builtin_trap is that there's no certain way to get the actual ud2a eip (ie, paste an asm label onto it). Right. Which is why we need to do it as an inline asm. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
On Tue, 24 Jul 2007, David Miller wrote:
From: Jeremy Fitzhardinge [EMAIL PROTECTED]
Date: Tue, 24 Jul 2007 23:24:55 -0700
H. Peter Anvin wrote:
How far back was __builtin_trap() supported?
I think its relatively recent, but it might be within our supported
compiler window.
I'm pretty sure it is.
.. and I'm pretty sure it's immaterial.
We don't just do the ud2 instruction - we also do the file and line
number information after it. Which means that __builtin_trap() is useless.
So we might as well keep the loop, since both are two-byte instructions
that tell gcc that it will never continue.
Umm... Actually, we might be able to do something like
{
l: __builtin_trap();
static struct ... v __attribute__((section(...))) = { l, n, file };
}
except that it would need block-local labels and those are ugly (so's
label, while we are at it)...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, Jul 25, 2007 at 10:19:55AM -0700, Linus Torvalds wrote: On Wed, 25 Jul 2007, Jeremy Fitzhardinge wrote: No, not any more. The file and line info is out of line, in a separate section, indexed by the ud2a's eip. That's irrelevant - the point is, we need to do the ud2 by hand, since we need to control the code generation in order to associate the ud2 with the proper file/linenr. The main problem with __builtin_trap is that there's no certain way to get the actual ud2a eip (ie, paste an asm label onto it). Right. Which is why we need to do it as an inline asm. Who said that we need to populate that section from asm? Define a static variable in that section inside a block; identifier is not a problem, obviously. I'm not saying that it's not revolting, but it's not impossible. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, Jul 25, 2007 at 10:22:15AM -0700, H. Peter Anvin wrote:
So we might as well keep the loop, since both are two-byte instructions
that tell gcc that it will never continue.
Umm... Actually, we might be able to do something like
{
l: __builtin_trap();
static struct ... v __attribute__((section(...))) = { l, n, file };
}
except that it would need block-local labels and those are ugly (so's
label, while we are at it)...
I thought gcc was buggy when it came to passing labels to assembly.
Where do you see passing label to assembly? More interesting question
is whether gcc believes it to be const...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Jeremy Fitzhardinge wrote: Linus Torvalds wrote: .. and I'm pretty sure it's immaterial. We don't just do the ud2 instruction - we also do the file and line number information after it. Which means that __builtin_trap() is useless. No, not any more. The file and line info is out of line, in a separate section, indexed by the ud2a's eip. The main problem with __builtin_trap is that there's no certain way to get the actual ud2a eip (ie, paste an asm label onto it). Same difference, then... -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote:
On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
On Tue, 24 Jul 2007, David Miller wrote:
From: Jeremy Fitzhardinge [EMAIL PROTECTED]
Date: Tue, 24 Jul 2007 23:24:55 -0700
H. Peter Anvin wrote:
How far back was __builtin_trap() supported?
I think its relatively recent, but it might be within our supported
compiler window.
I'm pretty sure it is.
.. and I'm pretty sure it's immaterial.
We don't just do the ud2 instruction - we also do the file and line
number information after it. Which means that __builtin_trap() is useless.
So we might as well keep the loop, since both are two-byte instructions
that tell gcc that it will never continue.
Umm... Actually, we might be able to do something like
{
l: __builtin_trap();
static struct ... v __attribute__((section(...))) = { l, n, file };
}
except that it would need block-local labels and those are ugly (so's
label, while we are at it)...
I thought gcc was buggy when it came to passing labels to assembly.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro [EMAIL PROTECTED] wrote: Where do you see passing label to assembly? More interesting question is whether gcc believes it to be const... Passing labels like that to assembly didn't used to work, which is a pity as we could speed up things like get_user() if it could be made to. David - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote: We don't just do the ud2 instruction - we also do the file and line number information after it. Which means that __builtin_trap() is useless. So we might as well keep the loop, since both are two-byte instructions that tell gcc that it will never continue. Actually, the worse problem is that gcc will happily merge these guys. And that's a killer. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: Who said that we need to populate that section from asm? Define a static variable in that section inside a block; identifier is not a problem, obviously. I'm not saying that it's not revolting, but it's not impossible. I tried that, but there's still no way of getting a pointer to the ud2a instruction in there. gcc just generates garbage if you try to use use the label syntax on a label which isn't (potentially) the target of a goto (it just gets placed somewhere random). But there's a bigger problem than that. If the BUG is in code which can be replicated (ie inlined or unrolled), then it would also require replicating the static variable... J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote: We don't just do the ud2 instruction - we also do the file and line number information after it. Which means that __builtin_trap() is useless. So we might as well keep the loop, since both are two-byte instructions that tell gcc that it will never continue. Actually, the worse problem is that gcc will happily merge these guys. And that's a killer. Merge __builtin_traps()? Ugh. But also, there's no real long-term guarantee that it will keep generating ud2a. The *only* mention of it in the manual is a discussion that it will emit a call to abort() on arches which don't otherwise support it. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote:
On Wed, Jul 25, 2007 at 09:56:12AM -0700, Linus Torvalds wrote:
On Tue, 24 Jul 2007, David Miller wrote:
From: Jeremy Fitzhardinge [EMAIL PROTECTED]
Date: Tue, 24 Jul 2007 23:24:55 -0700
H. Peter Anvin wrote:
How far back was __builtin_trap() supported?
I think its relatively recent, but it might be within our supported
compiler window.
I'm pretty sure it is.
.. and I'm pretty sure it's immaterial.
We don't just do the ud2 instruction - we also do the file and line
number information after it. Which means that __builtin_trap() is useless.
So we might as well keep the loop, since both are two-byte instructions
that tell gcc that it will never continue.
Umm... Actually, we might be able to do something like
{
l: __builtin_trap();
static struct ... v __attribute__((section(...))) = { l, n, file };
}
except that it would need block-local labels and those are ugly (so's
label, while we are at it)...
I couldn't get it to work. It would be nice, because it would more or
less eliminate the need for asm in setting up BUGs - particularly the
nasty asm setting up the structure.
But it just doesn't work. The label l ends up pointing to is not
anywhere near the __builtin_trap instruction; I found it tended to point
to the start of the function prologue.
I reported it as a gcc bug, but they refused to hear of it. Details at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
J
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
From: H. Peter Anvin [EMAIL PROTECTED] Date: Wed, 25 Jul 2007 13:37:00 -0700 Another useful extension was a variant of __builtin_trap() which would create a dummy ELF relocation for the trapping instruction with a target. That would be very useful. Another idea that has been tossed around is to build with dwarf2 debugging, scan a pre-linked kernel image for conditional trap instructions, and use the dwarf2 info to reconstruct the file and line number information into the table of BUG entries. Then perform the final link and strip the dwarf2 debugging info out. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
From: Jeremy Fitzhardinge [EMAIL PROTECTED] Date: Wed, 25 Jul 2007 10:36:49 -0700 I tried that, but there's still no way of getting a pointer to the ud2a instruction in there. gcc just generates garbage if you try to use use the label syntax on a label which isn't (potentially) the target of a goto (it just gets placed somewhere random). But there's a bigger problem than that. If the BUG is in code which can be replicated (ie inlined or unrolled), then it would also require replicating the static variable... Another issue is that if you have a conditional trap instruction on your cpu, and you try the __label__ trick, GCC no longer converts: BUG_ON(test) into just a: set condition codes; conditional_trap; sequence because the stuff inside the basic block is something more than just the __builtin_trap(). The holy grail would be being able to get the perfect conditional trap sequence, plus the annotations in a seperate section. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On 07/25/2007 01:41 PM, Jeremy Fitzhardinge wrote: I reported it as a gcc bug, but they refused to hear of it. Details at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305 Wow. I especially like You should plan a better way. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Chuck Ebbert wrote: On 07/25/2007 01:41 PM, Jeremy Fitzhardinge wrote: I reported it as a gcc bug, but they refused to hear of it. Details at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305 Wow. I especially like You should plan a better way. FWIW, at Transmeta we had a local extension to gcc called __builtin_not_reached() which we used to tell gcc that an assembly statement would terminate the control flow. Another useful extension was a variant of __builtin_trap() which would create a dummy ELF relocation for the trapping instruction with a target. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
David Miller wrote: Another issue is that if you have a conditional trap instruction on your cpu, and you try the __label__ trick, GCC no longer converts: BUG_ON(test) into just a: set condition codes; conditional_trap; sequence because the stuff inside the basic block is something more than just the __builtin_trap(). The holy grail would be being able to get the perfect conditional trap sequence, plus the annotations in a seperate section. I think that would require a custom gcc builtin, which we might be able to ask the gcc folks for... -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
From: Jeremy Fitzhardinge [EMAIL PROTECTED] Date: Wed, 25 Jul 2007 10:00:20 -0700 No, not any more. The file and line info is out of line, in a separate section, indexed by the ud2a's eip. The main problem with __builtin_trap is that there's no certain way to get the actual ud2a eip (ie, paste an asm label onto it). Yes, I tried very hard to accomplish this myself, it would be wonderful if it could be made to work. I tried tricks using __label__ in inline asm, everything. It would be workable if condition codes could be passed into inline asm statements somehow, or the address of the builtin_trap() could be reliably obtained. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Wed, 25 Jul 2007, Al Viro wrote:
Umm... Actually, we might be able to do something like
{
l: __builtin_trap();
static struct ... v __attribute__((section(...))) = { l, n, file };
No.
A C-level label is a pointer to a C-level construct.
The compiler may have reasons to put other instructions in between the
label and the final end result of the __builtin_trap. The above may work
for some trivial test-case, but in the end, the label and the __builtin
are *not* atomic, and the compiler may well end up having register spills
etc in there, or having CSE'd two traps, or any number of details meaning
that the label doesn't point to the exact ud2 instruction.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Keith Owens wrote: > Trent Piepho (on Tue, 24 Jul 2007 19:31:36 -0700 (PDT)) wrote: >> Adding __builtin_trap after the >> asm might be an ok fix. It will emit a spurious int 6, but that won't even >> be >> reached since the asm doesn't return, and it probably be less extra code than >> the loop. > > int 6 is a two byte instruction, the loop generates jmp with an 8 bit > offset, also two bytes. No change in code size. > INT 6 is #UD, so the __builtin_trap() replaces the ud2a as well as the loop. How far back was __builtin_trap() supported? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Trent Piepho (on Tue, 24 Jul 2007 19:31:36 -0700 (PDT)) wrote: >Adding __builtin_trap after the >asm might be an ok fix. It will emit a spurious int 6, but that won't even be >reached since the asm doesn't return, and it probably be less extra code than >the loop. int 6 is a two byte instruction, the loop generates jmp with an 8 bit offset, also two bytes. No change in code size. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Tue, 24 Jul 2007, Al Viro wrote: > AFAICS, the patch below should do it for i386; instead of > using a dummy loop to tell gcc that this sucker never returns, > we do > static void __always_inline __noreturn __BUG(const char *file, int line); > containing the actual asm we want to insert and define BUG() as > __BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough > experience with gcc __asm__ potential nastiness, so... Sounds like it doesn't work: http://gcc.gnu.org/ml/gcc/2007-02/msg00107.html [The] programmer won't get optimization he wants as after inlining this as after inlining this attribute information becomes completely lost. What about __builtin_trap? It results in int 6 that might not be applicable, but adding some control over it to i386 backend is definitly an option. Honza It seems like if __BUG() is not inlined, you get the bogus noreturn does return warning. If it is inlined, then you lose the noreturn attribute and un-reachable code paths aren't eliminated. Adding __builtin_trap after the asm might be an ok fix. It will emit a spurious int 6, but that won't even be reached since the asm doesn't return, and it probably be less extra code than the loop. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: > On Tue, Jul 24, 2007 at 12:13:19PM -0700, Jeremy Fitzhardinge wrote: > >> Al Viro wrote: >> >>> Works here... >>> >>> >> Hm, doesn't here: >> >> CC arch/i386/kernel/irq.o >> /home/jeremy/hg/xen/paravirt/linux/arch/i386/kernel/irq.c: In function >> '__BUG': >> include2/asm/bug.h:29: warning: 'noreturn' function does return >> >> This is with current FC7 distro gcc: gcc version 4.1.2 20070502 (Red Hat >> 4.1.2-12) >> > > Interesting... Looks like it's both version- and flags-dependent. > Oh, well... > > BTW, alpha, frv, m68k and s390 have BUG() that is not recognized as > noreturn by gcc. > Yes, it was something I added because I thought it would be useful. Traditionally, BUG has not affected gcc's control flow analysis. The other option is trying to use __builtin_trap, which happens to generate ud2a on i386. But I don't think its necessarily guaranteed to always do that, and I don't know if it does anything useful for other architectures. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Tue, Jul 24, 2007 at 12:13:19PM -0700, Jeremy Fitzhardinge wrote: > Al Viro wrote: > > Works here... > > > > Hm, doesn't here: > > CC arch/i386/kernel/irq.o > /home/jeremy/hg/xen/paravirt/linux/arch/i386/kernel/irq.c: In function > '__BUG': > include2/asm/bug.h:29: warning: 'noreturn' function does return > > This is with current FC7 distro gcc: gcc version 4.1.2 20070502 (Red Hat > 4.1.2-12) Interesting... Looks like it's both version- and flags-dependent. Oh, well... BTW, alpha, frv, m68k and s390 have BUG() that is not recognized as noreturn by gcc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: > Works here... > Hm, doesn't here: CC arch/i386/kernel/irq.o /home/jeremy/hg/xen/paravirt/linux/arch/i386/kernel/irq.c: In function '__BUG': include2/asm/bug.h:29: warning: 'noreturn' function does return This is with current FC7 distro gcc: gcc version 4.1.2 20070502 (Red Hat 4.1.2-12) J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Jeremy Fitzhardinge wrote: > H. Peter Anvin wrote: >> Could it be a gcc version difference? >> > > Likely. Well, we can always try it and see how much crap turns up. If > gcc keeps quiet about it, its certainly an improvement over the dummy loop. > > J You could do both, actually. If gcc sees the end without it, the loop will simply get dead-code eliminated. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
H. Peter Anvin wrote: > Could it be a gcc version difference? > Likely. Well, we can always try it and see how much crap turns up. If gcc keeps quiet about it, its certainly an improvement over the dummy loop. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: > On Tue, Jul 24, 2007 at 09:56:21AM -0700, Jeremy Fitzhardinge wrote: >> Al Viro wrote: >>> AFAICS, the patch below should do it for i386; instead of >>> using a dummy loop to tell gcc that this sucker never returns, >>> we do >>> static void __always_inline __noreturn __BUG(const char *file, int line); >>> containing the actual asm we want to insert and define BUG() as >>> __BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough >>> experience with gcc __asm__ potential nastiness, so... >>> >>> Comments, objections? >>> >> Does it work? When I wrote the BUG code I tried this, but gcc kept >> warning about "noreturn function returns". I couldn't work out a way to >> convince gcc that the asm is the end of the line. > > Works here... Could it be a gcc version difference? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Tue, Jul 24, 2007 at 09:56:21AM -0700, Jeremy Fitzhardinge wrote: > Al Viro wrote: > > AFAICS, the patch below should do it for i386; instead of > > using a dummy loop to tell gcc that this sucker never returns, > > we do > > static void __always_inline __noreturn __BUG(const char *file, int line); > > containing the actual asm we want to insert and define BUG() as > > __BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough > > experience with gcc __asm__ potential nastiness, so... > > > > Comments, objections? > > > > Does it work? When I wrote the BUG code I tried this, but gcc kept > warning about "noreturn function returns". I couldn't work out a way to > convince gcc that the asm is the end of the line. Works here... > I'm actually in favour of dropping the loop and the noreturn stuff > altogether. It means that gcc thinks everything is live at the time of > the BUG, and the debugging info at the point of the ud2a is more useful. It also means that gcc doesn't eliminate a bunch of codepaths. It means even more cretinous warnings about something being used uninitialized, etc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Jeremy Fitzhardinge wrote: > Al Viro wrote: >> AFAICS, the patch below should do it for i386; instead of >> using a dummy loop to tell gcc that this sucker never returns, >> we do >> static void __always_inline __noreturn __BUG(const char *file, int line); >> containing the actual asm we want to insert and define BUG() as >> __BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough >> experience with gcc __asm__ potential nastiness, so... >> >> Comments, objections? >> > > Does it work? When I wrote the BUG code I tried this, but gcc kept > warning about "noreturn function returns". I couldn't work out a way to > convince gcc that the asm is the end of the line. > > I'm actually in favour of dropping the loop and the noreturn stuff > altogether. It means that gcc thinks everything is live at the time of > the BUG, and the debugging info at the point of the ud2a is more useful. How much code would that add to the kernel? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: > AFAICS, the patch below should do it for i386; instead of > using a dummy loop to tell gcc that this sucker never returns, > we do > static void __always_inline __noreturn __BUG(const char *file, int line); > containing the actual asm we want to insert and define BUG() as > __BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough > experience with gcc __asm__ potential nastiness, so... > > Comments, objections? > Does it work? When I wrote the BUG code I tried this, but gcc kept warning about "noreturn function returns". I couldn't work out a way to convince gcc that the asm is the end of the line. I'm actually in favour of dropping the loop and the noreturn stuff altogether. It means that gcc thinks everything is live at the time of the BUG, and the debugging info at the point of the ud2a is more useful. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][RFC] getting rid of stupid loop in BUG()
AFAICS, the patch below should do it for i386; instead of
using a dummy loop to tell gcc that this sucker never returns,
we do
static void __always_inline __noreturn __BUG(const char *file, int line);
containing the actual asm we want to insert and define BUG() as
__BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough
experience with gcc __asm__ potential nastiness, so...
Comments, objections?
diff --git a/include/asm-i386/bug.h b/include/asm-i386/bug.h
index b0fd78c..294bc55 100644
--- a/include/asm-i386/bug.h
+++ b/include/asm-i386/bug.h
@@ -7,31 +7,27 @@
* The offending file and line are encoded encoded in the __bug_table section.
*/
-#ifdef CONFIG_BUG
#define HAVE_ARCH_BUG
-#ifdef CONFIG_DEBUG_BUGVERBOSE
-#define BUG() \
- do {\
- asm volatile("1:\tud2\n"\
-".pushsection __bug_table,\"a\"\n" \
-"2:\t.long 1b, %c0\n" \
-"\t.word %c1, 0\n" \
-"\t.org 2b+%c2\n" \
-".popsection" \
-: : "i" (__FILE__), "i" (__LINE__),\
-"i" (sizeof(struct bug_entry))); \
- for(;;) ; \
- } while(0)
+#define BUG() __BUG(__FILE__, __LINE__)
+
+#include
+#ifdef CONFIG_BUG
+static void __always_inline __noreturn __BUG(const char *file, int line)
+{
+#ifdef CONFIG_DEBUG_BUGVERBOSE
+ asm volatile("1:\tud2\n"
+".pushsection __bug_table,\"a\"\n"
+"2:\t.long 1b, %c0\n"
+"\t.word %c1, 0\n"
+"\t.org 2b+%c2\n"
+".popsection"
+: : "i" (file), "i" (line),
+"i" (sizeof(struct bug_entry)));
#else
-#define BUG() \
- do {\
- asm volatile("ud2");\
- for(;;) ; \
- } while(0)
+ asm volatile("ud2");
#endif
+}
#endif
-
-#include
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][RFC] getting rid of stupid loop in BUG()
AFAICS, the patch below should do it for i386; instead of
using a dummy loop to tell gcc that this sucker never returns,
we do
static void __always_inline __noreturn __BUG(const char *file, int line);
containing the actual asm we want to insert and define BUG() as
__BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough
experience with gcc __asm__ potential nastiness, so...
Comments, objections?
diff --git a/include/asm-i386/bug.h b/include/asm-i386/bug.h
index b0fd78c..294bc55 100644
--- a/include/asm-i386/bug.h
+++ b/include/asm-i386/bug.h
@@ -7,31 +7,27 @@
* The offending file and line are encoded encoded in the __bug_table section.
*/
-#ifdef CONFIG_BUG
#define HAVE_ARCH_BUG
-#ifdef CONFIG_DEBUG_BUGVERBOSE
-#define BUG() \
- do {\
- asm volatile(1:\tud2\n\
-.pushsection __bug_table,\a\\n \
-2:\t.long 1b, %c0\n \
-\t.word %c1, 0\n \
-\t.org 2b+%c2\n \
-.popsection \
-: : i (__FILE__), i (__LINE__),\
-i (sizeof(struct bug_entry))); \
- for(;;) ; \
- } while(0)
+#define BUG() __BUG(__FILE__, __LINE__)
+
+#include asm-generic/bug.h
+#ifdef CONFIG_BUG
+static void __always_inline __noreturn __BUG(const char *file, int line)
+{
+#ifdef CONFIG_DEBUG_BUGVERBOSE
+ asm volatile(1:\tud2\n
+.pushsection __bug_table,\a\\n
+2:\t.long 1b, %c0\n
+\t.word %c1, 0\n
+\t.org 2b+%c2\n
+.popsection
+: : i (file), i (line),
+i (sizeof(struct bug_entry)));
#else
-#define BUG() \
- do {\
- asm volatile(ud2);\
- for(;;) ; \
- } while(0)
+ asm volatile(ud2);
#endif
+}
#endif
-
-#include asm-generic/bug.h
#endif
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: AFAICS, the patch below should do it for i386; instead of using a dummy loop to tell gcc that this sucker never returns, we do static void __always_inline __noreturn __BUG(const char *file, int line); containing the actual asm we want to insert and define BUG() as __BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough experience with gcc __asm__ potential nastiness, so... Comments, objections? Does it work? When I wrote the BUG code I tried this, but gcc kept warning about noreturn function returns. I couldn't work out a way to convince gcc that the asm is the end of the line. I'm actually in favour of dropping the loop and the noreturn stuff altogether. It means that gcc thinks everything is live at the time of the BUG, and the debugging info at the point of the ud2a is more useful. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Jeremy Fitzhardinge wrote: Al Viro wrote: AFAICS, the patch below should do it for i386; instead of using a dummy loop to tell gcc that this sucker never returns, we do static void __always_inline __noreturn __BUG(const char *file, int line); containing the actual asm we want to insert and define BUG() as __BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough experience with gcc __asm__ potential nastiness, so... Comments, objections? Does it work? When I wrote the BUG code I tried this, but gcc kept warning about noreturn function returns. I couldn't work out a way to convince gcc that the asm is the end of the line. I'm actually in favour of dropping the loop and the noreturn stuff altogether. It means that gcc thinks everything is live at the time of the BUG, and the debugging info at the point of the ud2a is more useful. How much code would that add to the kernel? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Tue, Jul 24, 2007 at 09:56:21AM -0700, Jeremy Fitzhardinge wrote: Al Viro wrote: AFAICS, the patch below should do it for i386; instead of using a dummy loop to tell gcc that this sucker never returns, we do static void __always_inline __noreturn __BUG(const char *file, int line); containing the actual asm we want to insert and define BUG() as __BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough experience with gcc __asm__ potential nastiness, so... Comments, objections? Does it work? When I wrote the BUG code I tried this, but gcc kept warning about noreturn function returns. I couldn't work out a way to convince gcc that the asm is the end of the line. Works here... I'm actually in favour of dropping the loop and the noreturn stuff altogether. It means that gcc thinks everything is live at the time of the BUG, and the debugging info at the point of the ud2a is more useful. It also means that gcc doesn't eliminate a bunch of codepaths. It means even more cretinous warnings about something being used uninitialized, etc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: On Tue, Jul 24, 2007 at 09:56:21AM -0700, Jeremy Fitzhardinge wrote: Al Viro wrote: AFAICS, the patch below should do it for i386; instead of using a dummy loop to tell gcc that this sucker never returns, we do static void __always_inline __noreturn __BUG(const char *file, int line); containing the actual asm we want to insert and define BUG() as __BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough experience with gcc __asm__ potential nastiness, so... Comments, objections? Does it work? When I wrote the BUG code I tried this, but gcc kept warning about noreturn function returns. I couldn't work out a way to convince gcc that the asm is the end of the line. Works here... Could it be a gcc version difference? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
H. Peter Anvin wrote: Could it be a gcc version difference? Likely. Well, we can always try it and see how much crap turns up. If gcc keeps quiet about it, its certainly an improvement over the dummy loop. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Jeremy Fitzhardinge wrote: H. Peter Anvin wrote: Could it be a gcc version difference? Likely. Well, we can always try it and see how much crap turns up. If gcc keeps quiet about it, its certainly an improvement over the dummy loop. J You could do both, actually. If gcc sees the end without it, the loop will simply get dead-code eliminated. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: Works here... Hm, doesn't here: CC arch/i386/kernel/irq.o /home/jeremy/hg/xen/paravirt/linux/arch/i386/kernel/irq.c: In function '__BUG': include2/asm/bug.h:29: warning: 'noreturn' function does return This is with current FC7 distro gcc: gcc version 4.1.2 20070502 (Red Hat 4.1.2-12) J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Tue, Jul 24, 2007 at 12:13:19PM -0700, Jeremy Fitzhardinge wrote: Al Viro wrote: Works here... Hm, doesn't here: CC arch/i386/kernel/irq.o /home/jeremy/hg/xen/paravirt/linux/arch/i386/kernel/irq.c: In function '__BUG': include2/asm/bug.h:29: warning: 'noreturn' function does return This is with current FC7 distro gcc: gcc version 4.1.2 20070502 (Red Hat 4.1.2-12) Interesting... Looks like it's both version- and flags-dependent. Oh, well... BTW, alpha, frv, m68k and s390 have BUG() that is not recognized as noreturn by gcc. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Al Viro wrote: On Tue, Jul 24, 2007 at 12:13:19PM -0700, Jeremy Fitzhardinge wrote: Al Viro wrote: Works here... Hm, doesn't here: CC arch/i386/kernel/irq.o /home/jeremy/hg/xen/paravirt/linux/arch/i386/kernel/irq.c: In function '__BUG': include2/asm/bug.h:29: warning: 'noreturn' function does return This is with current FC7 distro gcc: gcc version 4.1.2 20070502 (Red Hat 4.1.2-12) Interesting... Looks like it's both version- and flags-dependent. Oh, well... BTW, alpha, frv, m68k and s390 have BUG() that is not recognized as noreturn by gcc. Yes, it was something I added because I thought it would be useful. Traditionally, BUG has not affected gcc's control flow analysis. The other option is trying to use __builtin_trap, which happens to generate ud2a on i386. But I don't think its necessarily guaranteed to always do that, and I don't know if it does anything useful for other architectures. J - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
On Tue, 24 Jul 2007, Al Viro wrote: AFAICS, the patch below should do it for i386; instead of using a dummy loop to tell gcc that this sucker never returns, we do static void __always_inline __noreturn __BUG(const char *file, int line); containing the actual asm we want to insert and define BUG() as __BUG(__FILE__, __LINE__). It looks safe, but I don't claim enough experience with gcc __asm__ potential nastiness, so... Sounds like it doesn't work: http://gcc.gnu.org/ml/gcc/2007-02/msg00107.html [The] programmer won't get optimization he wants as after inlining this as after inlining this attribute information becomes completely lost. What about __builtin_trap? It results in int 6 that might not be applicable, but adding some control over it to i386 backend is definitly an option. Honza It seems like if __BUG() is not inlined, you get the bogus noreturn does return warning. If it is inlined, then you lose the noreturn attribute and un-reachable code paths aren't eliminated. Adding __builtin_trap after the asm might be an ok fix. It will emit a spurious int 6, but that won't even be reached since the asm doesn't return, and it probably be less extra code than the loop. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Trent Piepho (on Tue, 24 Jul 2007 19:31:36 -0700 (PDT)) wrote: Adding __builtin_trap after the asm might be an ok fix. It will emit a spurious int 6, but that won't even be reached since the asm doesn't return, and it probably be less extra code than the loop. int 6 is a two byte instruction, the loop generates jmp with an 8 bit offset, also two bytes. No change in code size. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RFC] getting rid of stupid loop in BUG()
Keith Owens wrote: Trent Piepho (on Tue, 24 Jul 2007 19:31:36 -0700 (PDT)) wrote: Adding __builtin_trap after the asm might be an ok fix. It will emit a spurious int 6, but that won't even be reached since the asm doesn't return, and it probably be less extra code than the loop. int 6 is a two byte instruction, the loop generates jmp with an 8 bit offset, also two bytes. No change in code size. INT 6 is #UD, so the __builtin_trap() replaces the ud2a as well as the loop. How far back was __builtin_trap() supported? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
