On 06/30/2015 02:22 PM, Andy Lutomirski wrote:
> Hi all-
>
> I'm working on a massive set of cleanups to Linux's syscall handling.
> We currently have a nasty optimization in which we don't save rbx,
> rbp, r12, r13, r14, and r15 on x86_64 before calling C functions.
> This works, but it makes the
On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
> I'd say the most natural API for this would be to allow
> f{fixed,call-{used,saved}}-REG in target attribute.
Either that or
__attribute__((fixed(rbp,rcx),used(rax,rbx),saved(r11)))
... just to be shorter. Either way, I would consider this
On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
> On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin wrote:
>> On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
>>> I'd say the most natural API for this would be to allow
>>> f{fixed,call-{used,saved}}-REG in target
On 06/30/2015 02:55 PM, Andy Lutomirski wrote:
> On Tue, Jun 30, 2015 at 2:52 PM, H. Peter Anvin wrote:
>> On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
>>> On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin wrote:
>>>> On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
On 07/01/2015 10:43 AM, Jakub Jelinek wrote:
> On Wed, Jul 01, 2015 at 01:35:16PM -0400, Vladimir Makarov wrote:
>> Actually it raise a question for me. If we describe that a function
>> clobbers more than calling convention and then use it as a value (assigning
>> a variable or passing as an argu
On 09/22/15 01:41, David Chisnall wrote:
> On 21 Sep 2015, at 21:45, H.J. Lu via cfe-dev wrote:
>>
>> The main purpose of x86 interrupt attribute is to allow programmers
>> to write x86 interrupt/exception handlers in C WITHOUT assembly
>> stubs to avoid extra branch from assembly stubs to C funct
On 09/22/15 04:44, David Chisnall wrote:
> On 22 Sep 2015, at 12:39, H.J. Lu via cfe-dev wrote:
>>
>> The center piece of my proposal is not to change how parameters
>> are passed in compiler. As for user experience, the feedbacks on
>> my proposal from our users are very positive.
>
> Implement
On 09/22/15 04:52, David Chisnall wrote:
> On 22 Sep 2015, at 12:47, H.J. Lu wrote:
>>
>> since __builtin_exception_error () is the same as
>> __builtin_return_address (0) and __builtin_interrupt_data () is
>> address of __builtin_exception_error () + size of register.
>
> Except that they’re *no
On 05/04/2015 12:33 PM, Richard Henderson wrote:
>
> (0) The C level output variable should be an integral type, from bool on up.
>
> The flags are a scarse resource, easily clobbered. We cannot allow user code
> to keep data in the flags. While x86 does have lahf/sahf, they don't exactly
> per
On 05/04/2015 01:14 PM, H. Peter Anvin wrote:
>>
>> Therefore:
>>
>> (1) Each target defines a set of constraint strings,
>>
>>E.g. for x86, wherein we're almost out of constraint letters,
>>
>> ja aux carry flag
>> jc
On 05/04/2015 01:35 PM, Linus Torvalds wrote:
> On Mon, May 4, 2015 at 1:14 PM, H. Peter Anvin wrote:
>>
>> I would argue that for x86 what you actually want is to model the
>> *conditions* that are available on the flags, not the flags themselves.
>
> Yes. Otherwise
On 05/04/2015 01:57 PM, Richard Henderson wrote:
>
> Sure.
>
> I'd be more inclined to support these compound conditionals directly, rather
> than try to get the compiler to recognize them after the fact.
>
> Indeed, I believe we have a near complete set of them in the x86 backend
> already. It
For the x86 backend explicitly, is doing something like:
_Bool x;
asm("blah ; setc %0" : "=qm" (x));
... guaranteed to be safe for older versions of gcc?
-hpa
On 06/02/2015 06:02 PM, Richard Henderson wrote:
> On 06/02/2015 04:46 PM, H. Peter Anvin wrote:
>> For the x86 backend explicitly, is doing something like:
>>
>> _Bool x;
>>
>> asm("blah ; setc %0" : "=qm" (x));
>>
>> ... g
On 06/02/2015 11:23 PM, H.J. Lu wrote:
> Trampling code for nested functions puts code on stack.
This is an issue for the CS ≠ DS case, as opposed to _Bool, I assume.
In other words, we are okay if and only if we can run with an NX stack?
-hpa
a
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
-bit
system calls, otherwise we're planning to reuse the i386 compat system
calls, but invoke them via the syscall instruction (which requires a new
system call table) and to pass 64-bit arguments in single registers.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
ven on the i386 front we want people
to use the rt_sig* system calls. As a porting aid I can see it, but we
should avoid deprecated system calls in the final version.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 02/13/2011 01:16 PM, H. Peter Anvin wrote:
>
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system ca
On 02/13/2011 02:28 PM, Arnd Bergmann wrote:
> On Sunday 13 February 2011, H. Peter Anvin wrote:
>> The actual idea is to use the i386 compat ABI for memory layout, but
>> with a 64-bit register convention. That means that system calls that
>> don't make references to me
On 02/13/2011 01:33 PM, Alan Cox wrote:
Who actually needs this new extra API - whats the justification for
everyone having more crud dumping their kernels, more syscall paths
(which are one of the most security critical areas) and the like.
What are the benchmark numbers to justify this versus
On 02/13/2011 03:39 PM, Alan Cox wrote:
a. the int $0x80 instruction is much slower than syscall. An actual
i386 process can use the syscall instruction which is disambiguated
by the CPU based on mode, but an x32 process is in the same CPU mode
as a normal 64-bit process.
So set a
On 02/16/2011 11:22 AM, H.J. Lu wrote:
> Hi,
>
> I updated x32 psABI draft to version 0.2 to change x32 library path
> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
> Ubuntu and other derivative distributions. The new x32 psABI is
> available from:
>
> https://sites.goog
On 02/17/2011 10:06 AM, Jakub Jelinek wrote:
> On Thu, Feb 17, 2011 at 04:44:53PM +0100, Jan Hubicka wrote:
According to Mozilla folks however REL+RELA scheme used by EABI leads
to significandly smaller libxul.so size
According to http://glandium.org/blog/?p=1177 the difference
On 02/17/2011 02:49 PM, Jan Hubicka wrote:
>> On Thu, Feb 17, 2011 at 04:44:53PM +0100, Jan Hubicka wrote:
> According to Mozilla folks however REL+RELA scheme used by EABI leads
> to significandly smaller libxul.so size
>
> According to http://glandium.org/blog/?p=1177 the differen
On 05/21/2011 09:27 AM, H.J. Lu wrote:
> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu wrote:
>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann wrote:
>>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
This is the x32 project status update:
https://sites.google.com/site/x32abi/
>>
On 10/15/2009 08:56 AM, Richard Henderson wrote:
> On 10/15/2009 07:41 AM, Markus L wrote:
>> However the IS is designed so that it is beneficial to to store 16bit
>> values in the high part of the registers (rNh) and also the calling
>> conventions that we want follow require 16bit values to be pa
%ebp
> mov%esp,%ebp
> ...
> call mcount
>
The real questions is why we're aligning the stack in the kernel. It is
probably not what we want -- we don't use SSE for anything but a handful
of special cases in the kernel, and we don't want the o
On 11/19/2009 07:44 AM, Andrew Haley wrote:
>
> We're aligning the stack properly, as per the ABI requirements. Can't
> you just fix the tracer?
>
"Per the ABI requirements?" We're talking 32 bits, here.
-hpa
--
H. Peter Anvin, Intel Open Sour
hat? The hooks that are in place have no idea of what
> happened before they were called?
>
Furthermore, it is nonsense -- ABI stack alignment on *32 bits* is 4
bytes, not 16.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
ave
more than one such variable, the most efficient way -- and by far least
complex -- is for the compiler to align the stack when it sets up the
stack frame.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
27;t the
normal C ABI (the __fentry__ function would have to preserve all
registers), but that's fine...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On i386, if we call __fentry__ immediately on entry the return address will be
in 4(%esp), so I fail to see how you could not reliably have the return
address. Other arches would have different constraints, of course.
"Frederic Weisbecker" wrote:
>On Thu, Nov 19, 2009 at 03:05:41PM -0500, Ste
Hence a new unconstrained option...
"Jeff Law" wrote:
>On 11/19/09 12:50, H. Peter Anvin wrote:
>>
>> Calling the profiler immediately at the entry point is clearly the more
>> sane option. It means the ABI is well-defined, stable, and independent
>> of
On 11/19/2009 04:59 PM, Linus Torvalds wrote:
>
> [ Btw, looking at that, why are X86_L1_CACHE_BYTES and X86_L1_CACHE_SHIFT
> totally unrelated numbers? Very confusing. ]
>
Yes, there is another thread to clean up that particular mess; it is
already in -tip:
http://git.kernel.org/tip/350f8f5
very good idea to me.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 11/20/2009 04:34 AM, Steven Rostedt wrote:
>>
>> If there's interest I can polish it up and submit formally.
>
> I would definitely be interested, and I would also be willing to test
> it.
>
I don't think there is any question that interception at the
architectural entry point would be the ri
On 11/20/2009 11:46 AM, Steven Rostedt wrote:
>
> Yes a gcc test suite will help new instances of gcc. But we need to
> worry about the instances of gcc that people have on their desktops now.
> This test case will catch the discrepancy between gcc and the function
> graph tracer. I'm not 100% con
ions), but I guess since it's only when
tracing it's less of an issue.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 11/24/2009 09:12 AM, Andrew Haley wrote:
>>
>> If we're changing gcc anyway, then let's add the option of intercepting
>> the function at the point where the machine state is well-defined by
>> ABI, which is before the function stack frame is set up.
>
> Hmm. On the x86 I suppose we could just
On 11/24/2009 09:30 AM, Steven Rostedt wrote:
>
> For other archs, Linus showed some examples:
>
> http://lkml.org/lkml/2009/11/19/349
>
Yes; the key here is that the ABI-defined entry state is readily
mappable onto the state on entry to the __fentry__ function.
-hp
is/was a mistake.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
but at least also icc, the Solaris
compiler, and the Qlogic compiler... possibly others.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
there are failure scenarios where
gcc 3.4.6 expects a fully zeroed register (it produces them, I don't
know if it expects to consume them that way, too.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 12/08/2009 10:24 AM, H.J. Lu wrote:
>
> We should just drop
>
> ---
> When a value of type _Bool is passed in a register or on the stack,
> the upper 63 bits of the eightbyte shall be zero.
> ---
>
> from psABI. Since _Bool has one byte in size with values of 0 and 1.
> Compilers have to clea
On 12/09/2009 06:44 AM, H.J. Lu wrote:
>
> Aren't bits in the _Bool byte of"bar" specified by the psABI or the C
> language standard already?
>
The psABI, yes. They are obviously not defined by the C language standard.
-hpa
--
H. Peter Anvin, Intel Open
t is inconsistent for
arguments are return values; this is a bug in the wordsmithing of the
text rather than intentional, if I remember the original discussions
correctly.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 12/06/2010 02:30 PM, H.J. Lu wrote:
> Hi,
>
> "ld -r" doesn't work with mixed IR/non-IR objects:
>
> http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291
>
> Some compilers support it. Should it be supported?
>
As we discussed in person, I think it would be user friendly to support
it,
On 12/07/2010 04:20 PM, Andi Kleen wrote:
>
> The only problem left is mixing of lto and non lto objects. this right
> now is not handled. IMHO still the best way to handle it is to use
> slim lto and then simply separate link the "left overs" after deleting
> the LTO objects. This can be actually
On 12/07/2010 03:58 PM, Dave Korn wrote:
> On 07/12/2010 23:15, Cary Coutant wrote:
>
>>> ○ Object-only section:
>>> § Section name won't be generated by any tools, something like
>>> ".objectonly\004".
>>> § Contains non-IR object file.
>>> § Input
may generate ELF objects to generate this magic object. But why
> not just ELF directly? that is what it is after all.
>
No. You just need to teach the linker to generate it when you're doing
a ld -r on mixed objects.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Cent
t every time simply made it not worth it.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
only affect a handful of
structures in practice since implicit padding is frowned upon.
(a) could also be fixed by a different syscall dispatch table, it's not
the hard part of this. We definitely want to avoid adding a different
memory ABI; that's the part that hurts.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 12/30/2010 11:53 AM, Richard Guenther wrote:
>
> Would be nice if LFS would be mandatory on the new ABI, thus
> off_t being 64bits.
>
Yes, although that's a higher-order thing.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don
This means that the psABI must use the same size and
> alignment rules for in-memory structures as the i386 does.
>
No, it doesn't. It just means it need to do so *for the types used by
the kernel*. The kernel uses types like __u64, which would indeed have
to be declared aligned(4).
I believe it covers all cases *relevant for this particular situation* (unlike,
say, MIPS) and that any deviation is a bug which can and should be fixed.
"David Daney" wrote:
>On 12/30/2010 12:12 PM, H. Peter Anvin wrote:
>> On 12/30/2010 11:34 AM, David Daney wrote:
&g
We do have a slightly more extensive patch already implemented.
"Robert Millan" wrote:
>Hi folks,
>
>I had this unsubmitted patch in my local filesystem. It makes Linux
>detect ELF32 AMD64 binaries and sets a flag to restrict them to
>32-bit address space.
>
>It's not rocket science but can sav
Or perhaps automatic generation will actually get implemented. I wrote
an automatic syscall wrapper generator for klibc; one of the best design
decisions I made for that project.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
nts, to
> avoid the need to sign/zero extend twice, etc.
>
Ehwhat? x86-64 is completely unambiguous on that point; the i386 one is
not.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 12/30/2010 02:18 PM, Robert Millan wrote:
> 2010/12/30 H.J. Lu :
>> I also have a patch for gcc 4.4 which works on simple codes.
>>
>> H.J.
>> On Thu, Dec 30, 2010 at 1:31 PM, H. Peter Anvin wrote:
>>> We do have a slightly more extensive patch already im
e of
the i386 kernel ABI; I'm not sure.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 12/30/2010 01:08 PM, Robert Millan wrote:
> Hi folks,
>
> I had this unsubmitted patch in my local filesystem. It makes Linux
> detect ELF32 AMD64 binaries and sets a flag to restrict them to
> 32-bit address space.
>
> It's not rocket science but can save you some work in case you
> haven't
On 12/31/2010 02:03 AM, Jakub Jelinek wrote:
> On Thu, Dec 30, 2010 at 01:42:05PM -0800, H. Peter Anvin wrote:
>> On 12/30/2010 11:57 AM, Jakub Jelinek wrote:
>>>>
>>>> Would be nice if LFS would be mandatory on the new ABI, thus
>>>> off_t being 64bit
On 01/04/2011 09:56 AM, H.J. Lu wrote:
>>
>> I think it is a gross misconception to tie the ABI to the ELF class of
>> an object. Specifying the ABI should imo be done via e_flags or
>> one of the unused bytes of e_ident, and in all reality the ELF class
>> should *only* affect the file layout (and
On 01/04/2011 11:46 PM, Jan Beulich wrote:
>>>
>>> Oh god, please, no.
>>>
>>> I have to say I'm highly questioning to Jan's statement in the first
>>> place. Crossing 32- and 64-bit ELF like that sounds like a kernel
>>> security hole waiting to happen.
>
> A particular OS/kernel has the freedom
On 08/05/2013 09:55 AM, Steven Rostedt wrote:
>
> Almost a full year ago, Mathieu suggested something like:
>
> if (unlikely(x)) __attribute__((section(".unlikely"))) {
> ...
> } else __attribute__((section(".likely"))) {
> ...
> }
>
> https://lkml.org/lkml/2012/8/9/658
>
> Whic
On 08/05/2013 10:55 AM, Steven Rostedt wrote:
>
> Well, as tracepoints are being added quite a bit in Linux, my concern is
> with the inlined functions that they bring. With jump labels they are
> disabled in a very unlikely way (the static_key_false() is a nop to skip
> the code, and is dynamical
On 08/05/2013 11:23 AM, Steven Rostedt wrote:
> On Mon, 2013-08-05 at 11:17 -0700, H. Peter Anvin wrote:
>> On 08/05/2013 10:55 AM, Steven Rostedt wrote:
>>>
>>> Well, as tracepoints are being added quite a bit in Linux, my concern is
>>> with the inlined
On 08/05/2013 11:20 AM, Linus Torvalds wrote:
>
> Of course, it would be good to optimize static_key_false() itself -
> right now those static key jumps are always five bytes, and while they
> get nopped out, it would still be nice if there was some way to have
> just a two-byte nop (turning into
On 08/05/2013 11:34 AM, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
> wrote:
>>
>> Ugh. I can see the attraction of your section thing for that case, I
>> just get the feeling that we should be able to do better somehow.
>
> Hmm.. Quite frankly, Steven, for your use ca
On 08/05/2013 11:49 AM, Steven Rostedt wrote:
> On Mon, 2013-08-05 at 11:29 -0700, H. Peter Anvin wrote:
>
>> Traps nest, that's why there is a stack. (OK, so you don't want to take
>> the same trap inside the trap handler, but that code should be very
>> li
On 08/05/2013 02:28 PM, Mathieu Desnoyers wrote:
> * Linus Torvalds (torva...@linux-foundation.org) wrote:
>> On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers
>> wrote:
>>>
>>> I remember that choosing between 2 and 5 bytes nop in the asm goto was
>>> tricky: it had something to do with the fact
On 08/05/2013 09:14 PM, Mathieu Desnoyers wrote:
>>
>> For unconditional jmp that should be pretty safe barring any fundamental
>> changes to the instruction set, in which case we can enable it as
>> needed, but for extra robustness it probably should skip prefix bytes.
>
> On x86-32, some prefixe
On 08/06/2013 09:15 AM, Steven Rostedt wrote:
> On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote:
>
>> For unconditional jmp that should be pretty safe barring any fundamental
>> changes to the instruction set, in which case we can enable it as
>> needed, but
On 08/06/2013 09:26 AM, Steven Rostedt wrote:
>>
>> No, but if we ever end up doing MPX in the kernel, for example, we would
>> have to put an MPX prefix on the jmp.
>
> Well then we just have to update the rest of the jump label code :-)
>
For MPX in the kernel, this would be a small part of th
On 08/12/2013 02:17 AM, Peter Zijlstra wrote:
>
> I've been wanting to 'abuse' static_key/asm-goto to sort-of JIT
> if-forest functions like perf_prepare_sample() and perf_output_sample().
>
> They are of the form:
>
> void func(obj, args..)
> {
> unsigned long f = ...;
>
> if (f &
On 08/12/2013 09:09 AM, Peter Zijlstra wrote:
>>
>> On the majority of architectures, including x86, you cannot simply copy
>> a piece of code elsewhere and have it still work.
>
> I thought we used -fPIC which would allow just that.
>
Doubly wrong. The kernel is not compiled with -fPIC, nor do
> On Mon, Aug 12, 2013 at 10:47:37AM -0700, H. Peter Anvin wrote:
>> Since we really doesn't want to...
Ow. Can't believe I wrote that.
-hpa
On 04/13/2012 09:18 AM, H.J. Lu wrote:
> Hi,
>
> We need a reliable way to tell if we are compiling for x32 through
> pre-defined preprocessor symbol. __LP64/__LP64__ aren't
> specified by x86-64 psABI, although they have been added to
> GCC 3.3. They can't be counted on to detect x32 since not
On 05/14/2012 10:31 AM, H.J. Lu wrote:
> Hi,
>
> Support for the x32 psABI:
>
> http://sites.google.com/site/x32abi/
>
> is added in Linux kernel 3.4-rc1. X32 uses the ILP32 model for x86-64
> instruction set with size of long and pointers == 4 bytes. X32 is
> already supported in GCC 4.7.0 an
On 06/26/2012 12:47 PM, H.J. Lu wrote:
>>
>> May I ask why the decision was made to use ILP32 instead of L64P32? The
>> latter would seem to avoid lots of porting problems in particular. And if
>> porting difficulties are the major complained about x32, is it really too
>> late to switch? Thank
On 06/28/2012 02:03 PM, Mark Butler wrote:
On Tuesday, June 26, 2012 1:53:01 PM UTC-6, H. Peter Anvin wrote:
It's worth noting that there are *no* Linux platforms that are not
ILP32
or LP64, so adding a third memory model is likely to cause even more
problems...
Ca
On 12/12/2012 01:07 PM, David Brown wrote:
I believe it has been a very long time since any manufacturers made a
pure 386 chip.
I believe embedded 386 production ceased in 2007.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on
Aurelien Jarno wrote:
Hi all,
Since version 4.3, gcc changed its behaviour concerning the x86/x86-64
ABI and the direction flag, that is it now assumes that the direction
flag is cleared at the entry of a function and it doesn't clear once
more if needed.
This causes some problems with the
Michael Matz wrote:
Hi,
On Wed, 5 Mar 2008, Aurelien Jarno wrote:
So I think gcc at least needs an *option* to revert to the old behavior,
and there's a good argument to make it the default for now, at least for
x86/x86-64 on Linux.
And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, Net
Jan Hubicka wrote:
Yes, if there are four kernels that get it "wrong", that effectively means
that the ABI document doesn't describe reality and gcc has to adjust.
Kernels almost never follow ABI used by applications to last detail.
Linux kernel is disabling red zone and use kernel code model,
Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3 since more than
three month.
Well, how often do you take a trap inside an overlapping memmove()?
-hpa
Chris Lattner wrote:
On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3 since
more than
three month.
Well, how often do you take a trap inside an overlapping memmove()?
How hard is it to chang
Michael Matz wrote:
Many bugs are a big issue to people who actually hit them, and we had (and
probably still have) far nastier corner case miscompilations here and
there and nevertheless released. It never was the end of the world :)
This is the sort of stuff that security holes are made
Chris Lattner wrote:
Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3 since
more
than
three month.
Well, how often do you take a trap inside an overlapping memmove()?
How hard is it to change the kernel signal entry path from "pushf" to
"pushf;cld"? Pro
Chris Lattner wrote:
Upon return to userspace, the modified state kicks in. Thus the
signal handler is entered with DF from userspace at trap time, not DF=0.
So it's an asynchronous state leak from one piece of userspace to
another.
Fine, it can happen either way. In either case, the dis
Jakub Jelinek wrote:
On Thu, Mar 06, 2008 at 09:44:05AM +0100, Andi Kleen wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3 since
more than
three month.
Well, how often do you
H.J. Lu wrote:
I agree with it. There is no right or wrong here Let's start from
scratch and figure out
what is the best way to handle this, assuming we are defining a new psABI.
No, I believe the right way to approach this is by applying the good
old-fashioned principle from Ask Mr. Protocol
H.J. Lu wrote:
On Thu, Mar 6, 2008 at 8:23 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> H.J. Lu wrote:
> >I agree with it. There is no right or wrong here Let's start from
> >scratch and figure out
Robert Dewar wrote:
H.J. Lu wrote:
So that is the bug in the Linux kernel. Since fixing kernel is much
easier
than providing a workaround in compilers, I think kernel should be fixed
and no need for icc/gcc fix.
Fixing a bug in the Linux kernel is not "much easier". You are taking
a purely e
H.J. Lu wrote:
Not a fix, an (optional) workaround for a system bug.
So that is the bug in the Linux kernel. Since fixing kernel is much easier
than providing a workaround in compilers, I think kernel should be fixed
and no need for icc/gcc fix.
The problem is, you're going to have to be a
Robert Dewar wrote:
Sounds good, but has almost nothing to do with the real world. I
remember back in Realia COBOL days, we had to carefully copy IBM
bugs in the IBM mainframe COBOL compiler. Doing things right and
fixing the bug would have been the right thing to do, but no one
would have use
Robert Dewar wrote:
Not really, it's just a matter of time. Typical distro cycles are on
the order of 3 years.
-hpa
again, in the real world, there are MANY projects that are nothing
like this interactive when it comes to moving to new versions of
operating systems.
This is true, but
Richard Guenther wrote:
A patched GCC IMHO makes only sense if it is always-on, yet another option
won't help in corner cases. And corner cases is exactly what people seem
to care about. For this reason that we have this single release, 4.3.0, that
behaves "bad" is already a problem.
The op
99 matches
Mail list logo
