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 aroun
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
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 "unsubscrib
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" ins
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 targ
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
> (i
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
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-b
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
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 gettin
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
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
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() supporte
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();
> > s
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 u
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?
> >
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
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 in
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
secti
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
> > compi
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 su
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 thi
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
c
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.
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,
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 an
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':
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: 'noretur
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 (
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 g
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
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(con
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
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
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
> _
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__).
36 matches
Mail list logo
