Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
"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 take a trap inside an overlapping memmove()?
That was the state with older gcc, but with newer gcc it does not necessarily
reset the flag before the next function call.
so e.g. if you have
memmove(...)
for (... very long loop ) {
/* no function calls */
/* signals happen */
}
the signal could see the direction flag
-Andi
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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 take a trap inside an overlapping memmove()?
>
> That was the state with older gcc, but with newer gcc it does not necessarily
> reset the flag before the next function call.
>
> so e.g. if you have
>
> memmove(...)
> for (... very long loop ) {
> /* no function calls */
> /* signals happen */
> }
>
> the signal could see the direction flag
memmove is supposed to (and does) do a cld insn after it finishes the
backward copying.
Jakub
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: > It's a kernel bug, and it needs to be fixed. The discussion is about > what to do in the meantime. While it is known that 32-bit glibc memmove and also inlines for memmove and memrchr use std; some string op; cld;, 64-bit glibc doesn't ever use std instruction. gcc itself never generates std instruction. So, I've disassebled the whole Fedora/x86_64 distro (64-bit binaries/shared libraries/archives/object files, unpacked over 12000 rpms) to see how common is std insn in 64-bit code. The only positive hits were the kernel (/boot/xen-syms-2.6.21.7-2897.fc9 in particular, whatever that is) and libpolyml.so.1.0.0 (polyml-libs - this one has handwritten assembly in NASM), though I had to skim through some false positives (0xfd byte appearing in data within code sections, but it is easy to see if 0xfd is surrounded by invalid or nonsensical instructions that it is actually data). The conclusion is that DF=1 in x86_64 64-bit code is extremely rare. Therefore, if we decide to apply a workaround for the kernel bug in gcc (I'm not convinced we should), it should be IMNSHO limited to 32-bit code. Jakub
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Aurelien Jarno wrote: > H. Peter Anvin a écrit : >> Michael Matz wrote: >>> >>> 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, NetBSD 4.0, they have the same behaviour as Linux, that is they don't clear DF before calling the signal handler. >>> Sigh. We could perhaps insert a cld for all functions which can be >>> recognized as possible signal handlers and call other unknown or >>> string functions. But it's probably even faster to emit cld in front >>> of the inline copies of mem functions again :-( >>> >> Well, there is a (slight) difference: you know that a called function >> will not clobber your DF state; it's only the entry condition which is >> imprecise. >> >> The best would be if this could be controlled by a flag, which we can >> flip once kernel fixes has been around for long enough. > > I have to agree there. Whatever the decision that gcc will take, > distributions will reenable the old behaviour for some time for to allow > upgrades from a previous version. > > Providing a flag to switch the behaviour (whatever the default > behaviour) will help a lot. I think you've got the timescales wrong. Anything that we do now in gcc will take a while to percolate to the Linux distributions. It is far quicker for those distributions to fix their kernels as fast as possible. By the time any gcc fix is in the world all of this will be over. I suppose one could apply the precautionary principle, but those systems that don't update kernels won't update gcc either, so the solution won't work. Andrew.
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Aurelien Jarno writes: > On Wed, Mar 05, 2008 at 11:58:34AM -0800, Joe Buck wrote: > > > > Aurelien Jarno wrote: > > > >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. > > > >... > > > >I guess this has to be fixed on the kernel side, but also gcc-4.3 could > > > >revert back to the old behaviour, that is clearing the direction flag > > > >when entering a routine that touches it until most people are running a > > > >fixed kernel. > > > > On Wed, Mar 05, 2008 at 08:00:42AM -0800, H. Peter Anvin wrote: > > > Linux should definitely follow the ABI. This is a bug, and a pretty > > > serious such. > > > > Unfortunately, there are a lot of kernels out there already with this > > problem, and the symptoms are likely to be subtle. So even if it is true > > that it is the kernel that is "in the wrong", I think we still are going > > to need to give users a workaround from the gcc side as well. > > > > 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, NetBSD 4.0, > they have the same behaviour as Linux, that is they don't clear DF > before calling the signal handler. FWIW, Solaris 10 (both 32- and 64-bit) gets it right.
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Andrew Haley <[EMAIL PROTECTED]> writes: > > I suppose one could apply the precautionary principle, but those systems that > don't update kernels won't update gcc either, so the solution won't work. You seem to assume that running a gcc 4.3 compiled binary requires a gcc update. That is not necessarily true. -Andi
GCC 4.3.0 Status Report (2008-03-06)
Status == GCC 4.3.0 release has been tagged in SVN, tarballs uploaded to gcc.gnu.org (though not to ftp.gnu.org yet). The branch is still frozen though, until we agree on what if anything to do about the implied cld instructions on i?86/x86_64. Hopefully this will not take long. The options are do nothing (it is a kernel bug and it is easiest to fix it there), or provide a workaround (don't need to step back to the old way, where we inserted cld before string insns even when some function was called since last time cld was emitted in the current function, only one cld between prologue and any string insn in the function is enough), where the workaround can be either optional (e.g. with default determined at configure time), or unconditional, and can be used for both -m32 and -m64 code, or just -m32 code (as in 64-bit code std is extremely rare). Jakub
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On 06 Mar 2008 12:45:57 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > I suppose one could apply the precautionary principle, but those systems > that > > don't update kernels won't update gcc either, so the solution won't work. > > You seem to assume that running a gcc 4.3 compiled binary requires a > gcc update. That is not necessarily true. It (sometimes) requires a libgcc and libstdc++ update. Richard.
GCC 4.3 - Error: Link tests are not allowed after GCC_NO_EXECUTABLES
When building GCC 4.3.0 for any newlib target I get: ... supports shared libraries... yes checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/gcc/build-gcc' make: *** [all] Error 2 I am using binutils 2.18, newlib 1.16.0 and Cygwin 1.5.24. The configure line is: ../gcc-4.3.0/configure --prefix=/usr/local/gcc-4.3.0-i686-elf --target=i686-elf --with-gnu-as --with-gnu-ld --with-newlib --with-headers=/gcc/newlib-1.16.0/newlib/libc/include --disable-shared --disable-libssp --enable-languages=c,c++ I searched for this error and found: http://gcc.gnu.org/ml/gcc/2007-09/msg00421.html Wasn't this patched? How do I fix this? Regards, Hans Kester
Enum in namespace
Hi!
namespace A {
enum A {
x
};
}
void f()
{
A::A a;
using namespace A;
a = x;
}
works whereas
namespace A {
enum A {
x
};
}
void f()
{
using namespace A;
A::A a;
a = x;
}
gives the following error:
test.cc: In function 'void f()':
test.cc:10: error: reference to 'A' is ambiguous
test.cc:1: error: candidates are: namespace A { }
test.cc:2: error: enum A::A
Since A::A is fully qualified it should be clear that the first A is the
namespace and the second the enum.
Is this a bug or am I too demanding?
Thanks,
G
[tuples] Merged trunk->branch @132948
It had been a while, so this merge was fairly long. It exposed a bug in complex lowering (we were not splitting the basic block properly when expanding complex divisions) and the ppc back end still hadn't been updated for the new walk_gimple_stmt interface. I also changed all the gimple_locus() and related functions to use 'location' instead of 'locus'. Tom Tromey's location_t patch is now in the branch so we don't have to deal with the ugly #ifdefs. The function gimple_locus_empty_p was mostly used with a ! in front, so I changed it to gimple_has_location to make predicates easier to read. Tested on x86, x86_64 and ppc64. Diego.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: > It's a kernel bug, and it needs to be fixed. I'm not convinced. It's been that way for 15 years, it's that way in the BSD kernels, at that point it's a feature. The bug is in the documentation, nowhere else. And in gcc for blindly trusting the documentation. OG.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Olivier Galibert wrote: > On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote: >> Olivier Galibert wrote: >>> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: It's a kernel bug, and it needs to be fixed. >>> I'm not convinced. It's been that way for 15 years, it's that way in >>> the BSD kernels, at that point it's a feature. The bug is in the >>> documentation, nowhere else. And in gcc for blindly trusting the >>> documentation. >> No, the bug *in the kernel* was already present (if you had a signal >> raised during a call to memmove). It's just more visible with GCC 4.3. > > I'm curious, since when paper documentation became the Truth and > reality became a bug? Isn't that the definition of a bug? That a program does not meet its specification? Andrew.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Olivier Galibert wrote: On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: It's a kernel bug, and it needs to be fixed. I'm not convinced. It's been that way for 15 years, it's that way in the BSD kernels, at that point it's a feature. The bug is in the documentation, nowhere else. And in gcc for blindly trusting the documentation. No, the bug *in the kernel* was already present (if you had a signal raised during a call to memmove). It's just more visible with GCC 4.3. Paolo
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote: > Olivier Galibert wrote: > >On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: > >>It's a kernel bug, and it needs to be fixed. > > > >I'm not convinced. It's been that way for 15 years, it's that way in > >the BSD kernels, at that point it's a feature. The bug is in the > >documentation, nowhere else. And in gcc for blindly trusting the > >documentation. > > No, the bug *in the kernel* was already present (if you had a signal > raised during a call to memmove). It's just more visible with GCC 4.3. I'm curious, since when paper documentation became the Truth and reality became a bug? OG.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Wed, Mar 05, 2008 at 03:21:43PM -0800, David Daney wrote: > Olivier Galibert wrote: > >On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote: > >>FWIW I don't think it's a release blocker for 4.3.0. The error is arcane > >>and happens seldomly if at all. And only on unfixed kernels. A program > >>needs to do std explicitely, which most don't do _and_ get hit by a > >>signal while begin in a std region. This happens so seldom that it > >>didn't occur in building the next openSuSE 11.0, and it continually > >>builds packages with 4.3 since months. > > > >How would you know whether it has happened? > > > > The same way you do with other bugs: You would observe unexpected behavior. > > In this case probably either corrupted memory or a SIGSEGV. So that probably means the programs you use for compiling packages probably aren't hit. Doesn't mean the packages you've compiled with it aren't hit. Compiling packages doesn't test what's in them at all. It's extremely rare, no doubt about it. It's just that it *yells* security issue in the making. It's not a source bug, i.e. not easily reviewable. It's related to signal handlers which are the mark of a server and/or more failure-conscious program than usual. It's obscure (breaking a stringop, probably memset, or a not-paranoid-enough inline asm in a signal handler through a running memmove in the main program, oh my) but reasonably predictable for someone looking for an exploitable flaw. It's gcc's job to adapt to the realities of its running environment, not the other way around. OG.
Re: [PATCH][4.3] Deprecate -ftrapv
FX Coudert wrote: [ Sorry, I'm way, way behind ] C: integer overflow undefined, checking desirable at least for debugging purposes. I think latest Fortran is same as C, can someone confirm? Yes, it is. Overflow undefined and no checking required; I think very few Fortran users actually use (or would use) checking on signed overflow. In Fortran, integers are used to index arrays. So if you want integer overflow checking, use -fbounds-check :-) -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/ml/gcc/2008-01/msg9.html
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Olivier Galibert wrote: On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: It's a kernel bug, and it needs to be fixed. I'm not convinced. It's been that way for 15 years, it's that way in the BSD kernels, at that point it's a feature. The bug is in the documentation, nowhere else. And in gcc for blindly trusting the documentation. I agree, it reminds me of Burroughs on the 5500 believing the Fortran standard which carefully allowed for a stack based implementation of Fortran, Algol-style, unfortunately no real Fortran programs worked with this semantics, and it was one of the factors contributing the demise of the 5500. OG.
Re: [PATCH][4.3] Deprecate -ftrapv
Toon Moene wrote: In Fortran, integers are used to index arrays. So if you want integer overflow checking, use -fbounds-check :-) I know there is a smiley here, but it seems to me that range checking is quite different from overflow checking.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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 take a trap inside an overlapping memmove()?
That was the state with older gcc, but with newer gcc it does not necessarily
reset the flag before the next function call.
If so, that's a much worse bug.
so e.g. if you have
memmove(...)
for (... very long loop ) {
/* no function calls */
/* signals happen */
}
the signal could see the direction flag
memmove is supposed to (and does) do a cld insn after it finishes the
backward copying.
You can still take a signal inside memmove() itself, of course.
-hpa
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On 3/6/08, Olivier Galibert <[EMAIL PROTECTED]> wrote: > On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: > > It's a kernel bug, and it needs to be fixed. > > I'm not convinced. It's been that way for 15 years, it's that way in > the BSD kernels, at that point it's a feature. The bug is in the > documentation, nowhere else. And in gcc for blindly trusting the > documentation. The issue should not be evaluated as: "It's always been that way, therefore, it's right." Instead, it should be: "What's the right way to do it?" You don't just change documentation because no existing code meets the requirement -- UNLESS -- the non-conforming code is actually the right way to do things.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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. H.J. On Thu, Mar 6, 2008 at 7:37 AM, NightStrike <[EMAIL PROTECTED]> wrote: > > On 3/6/08, Olivier Galibert <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: > > > It's a kernel bug, and it needs to be fixed. > > > > I'm not convinced. It's been that way for 15 years, it's that way in > > the BSD kernels, at that point it's a feature. The bug is in the > > documentation, nowhere else. And in gcc for blindly trusting the > > documentation. > > The issue should not be evaluated as: "It's always been that way, > therefore, it's right." Instead, it should be: "What's the right way > to do it?" > > You don't just change documentation because no existing code meets the > requirement -- UNLESS -- the non-conforming code is actually the right > way to do things. >
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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: Be liberal in what you receive, conservative in what you send In other words: a. Fix the kernel. Already in progress. b. Do *not* make gcc assume DF is clean for now. Adding a switch would be a useful thing, since if nothing else it would benefit embedded environments. We might assume DF is clean on 64 bits, since it appears it is rarely used anyway, and 64 bits is more important in the long run. c. Once fixed kernels have been out long enough, we can flip the default of the switch, one platform at a time if need be (e.g. there may never be another SCO OpenServer.) -hpa
Injecting data declarations?
Hi, I would like to modify GCC to inject a link-once word-sized data declaration into the object file, i.e. to behave AS IF there were extra declarations in the source code, e.g.: void* __secret__Foo = &Foo; (Where Foo is some piece of static data that was defined in source.) Can someone give me a pointer? I imagine I need to call 'start_decl' and 'finish_decl', but how do I create the declarator tree for start_decl? How do I specify the type? Many thanks, -- Reuben
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
NightStrike wrote: On 3/6/08, Olivier Galibert <[EMAIL PROTECTED]> wrote: On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: It's a kernel bug, and it needs to be fixed. I'm not convinced. It's been that way for 15 years, it's that way in the BSD kernels, at that point it's a feature. The bug is in the documentation, nowhere else. And in gcc for blindly trusting the documentation. The issue should not be evaluated as: "It's always been that way, therefore, it's right." Instead, it should be: "What's the right way to do it?" You don't just change documentation because no existing code meets the requirement -- UNLESS -- the non-conforming code is actually the right way to do things. 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 used Realia COBOL :-) Another story, the sad story of the intel chip (I think it was the 80188) where Intel made use of Int 5, which was documented as reserved. Unfortunately, Microsoft/IBM had used this for print screen or some such. Intel was absolutely right that their documentation was clear and it was wrong to have used these interrupts .. but the result was a warehouse of unused chips.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Olivier Galibert wrote: > On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: >> It's a kernel bug, and it needs to be fixed. > > I'm not convinced. It's been that way for 15 years, it's that way in > the BSD kernels, at that point it's a feature. The bug is in the > documentation, nowhere else. And in gcc for blindly trusting the > documentation. well, you could see this either way -- either the kernel is buggy and needs to be fixed or the current behavior is correct and the abi needs an errata. If there were no performance implications i'd go for the latter, mostly because of the security aspect. But this thread made me dig up an old benchmark and apparently omitting the cld before the string ops makes a significant difference; on P2 it was ~8%, on P4 it's ~6% for 1480 byte copies; for 32 byte ones the gain is more like 90% on a P4 [1]. So the impact on small structure memcpy/memset etc is significant, hence fixing the kernel looks like a better long term plan. artur [1] P4 # ./bcsp m IACCK 0.9.29 Artur Skawina <...> [ exec time; lower is better ] [speed ] [ time ] [ok?] TIME-N+S TIME32 TIME33 TIME1480 MBYTES/S TIME CSUM FUNCTION ( rdtsc_overhead=0 null=0 ) 0 0 00 inf0 csum_partial_copy_null 1885375389 156 7589.7439350 0 generic_memcpy 10894532666 1696 698.11 108557 0 kernel_memcpylib 1804325346 151 7841.0619614 0 kernel_memcpy686 1804325346 151 7841.0619693 0 kernel_memcpy686ncld 1744323381 148 8000.0019687 0 kernel_memcpy686as1 1332157232 139 8517.9919235 0 kernel_memcpy686as1ncld 1782318339 148 8000.0019607 0 kernel_memcpy686as2 1371168189 139 8517.9919221 0 kernel_memcpy686as2ncld P2 # ./bcsp m IACKK 0.9.28 Artur Skawina <...> TIME-N+S TIME32 TIME33 TIME1480 MBYTES/S TIME CKSUM FUNCTION ( rdtsc_overhead=1 null=0 ) 0000 inf0 : csum_partial_copy_null 7121 746 1215 730 1621.92 127418 : 0 generic_memcpy 43604 2032 1709 6574 180.10 416409 : 0 kernel_memcpylib 7480 771 726 684 1730.9996084 : 0 kernel_memcpy686 7036 735 543 685 1728.4795508 : 0 kernel_memcpy686ncld 7498 1015 711 716 1653.6392200 : 0 kernel_memcpy686as1 5826 438 489 662 1788.5291598 : 0 kernel_memcpy686as1ncld 6667 657 488 708 1672.3289366 : 0 kernel_memcpy686as2 6614 456 270 658 1799.3991203 : 0 kernel_memcpy686as2ncld
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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
> >what is the best way to handle this, assuming we are defining a new psABI.
BTW, just tested icc and icc doesn't generate cld either (so it matches the
new gcc behavior).
char buf1[32], buf2[32];
void bar (void);
void foo (void)
{
__builtin_memset (buf1, 0, 32);
bar ();
__builtin_memset (buf2, 0, 32);
}
Jakub
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Hi,
On Thu, Mar 6, 2008 at 6:23 PM, 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
> > >what is the best way to handle this, assuming we are defining a new psABI.
>
> BTW, just tested icc and icc doesn't generate cld either (so it matches the
> new gcc behavior).
> char buf1[32], buf2[32];
> void bar (void);
> void foo (void)
> {
> __builtin_memset (buf1, 0, 32);
> bar ();
> __builtin_memset (buf2, 0, 32);
> }
Also LKML discussion pointed out that Solaris gets this right too.
Regards,
ismail
--
Never learn by your mistakes, if you do you may never dare to try again.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Another story, the sad story of the intel chip (I think it was the 80188) where Intel made use of Int 5, which was documented as reserved. Unfortunately, Microsoft/IBM had used this for print screen or some such. Intel was absolutely right that their documentation was clear and it was wrong to have used these interrupts .. but the result was a warehouse of unused chips. Not really. Just, no one used the BOUND instruction. All computers running DOS (Intel, AMD, even the old NEC V20/V30 chips) still connect INT 5 to Print Screen. Paolo
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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
> > >what is the best way to handle this, assuming we are defining a new psABI.
>
> BTW, just tested icc and icc doesn't generate cld either (so it matches the
> new gcc behavior).
> char buf1[32], buf2[32];
> void bar (void);
> void foo (void)
> {
> __builtin_memset (buf1, 0, 32);
> bar ();
> __builtin_memset (buf2, 0, 32);
> }
>
Icc follows the psABI. If we are saying icc/gcc 4.3 need a fix, we'd
better define
a new psABI first.
H.J.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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
> >what is the best way to handle this, assuming we are defining a new psABI.
BTW, just tested icc and icc doesn't generate cld either (so it matches the
new gcc behavior).
char buf1[32], buf2[32];
void bar (void);
void foo (void)
{
__builtin_memset (buf1, 0, 32);
bar ();
__builtin_memset (buf2, 0, 32);
}
Icc follows the psABI. If we are saying icc/gcc 4.3 need a fix, we'd
better define
a new psABI first.
Not a fix, an (optional) workaround for a system bug.
-hpa
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 6, 2008 at 9:06 AM, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> 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
> >> > >what is the best way to handle this, assuming we are defining a new
> psABI.
> >>
> >> BTW, just tested icc and icc doesn't generate cld either (so it matches
> the
> >> new gcc behavior).
> >> char buf1[32], buf2[32];
> >> void bar (void);
> >> void foo (void)
> >> {
> >> __builtin_memset (buf1, 0, 32);
> >> bar ();
> >> __builtin_memset (buf2, 0, 32);
> >> }
> >>
> >
> > Icc follows the psABI. If we are saying icc/gcc 4.3 need a fix, we'd
> > better define
> > a new psABI first.
> >
>
> 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.
H.J.
Re: GCC 4.4 schedule
> "Richard" == Richard Guenther <[EMAIL PROTECTED]> writes: Richard> I am aware of the following merge candidates: the LTO branch, the Richard> incremental compiler branch, the selective scheduling branch, the Richard> YARA branch and of course the tuples branch. FWIW I'm not sure if the incremental compiler branch will be in a merge-worthy state during this stage 1 or not. I will try to submit some pieces of it though, particularly late gimplification and also identifier GC. These aren't really big enough to need special treatment. Tom
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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 engineering viewpoint, but life is not like that. There are lots of copies of Linux kernels around and in use. The issue is not fixing the kernel per se, it is propagating that change to all Linux kernels in use -- THAT'S another matter entirely, and is far far more difficult than making sure that a kernel fix is qualified and widely proopagated. H.J.
Re: [PATCH][4.3] Deprecate -ftrapv
In Fortran, integers are used to index arrays. So if you want integer overflow checking, use -fbounds-check :-) I know there is a smiley here, but it seems to me that range checking is quite different from overflow checking. I think what Toon was alluding to is that "real" Fortran programmers don't use integers except for array subscripts. Real life is floating- point based! FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
GCC 4.3.0 Status Report (2008-03-06, 2nd editionOF)
Status update = The GCC 4.3 branch is now open for commits under normal release branch rules. GCC 4.3.1 should be released earlier than after two months. If we have the workaround soon, we might cut 4.3.1-rc1 e.g. in two weeks or so, depending on how well tested it will be then and depending on other changes on the branch. Jakub
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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 engineering viewpoint, but life is not like that. There are lots of copies of Linux kernels around and in use. The issue is not fixing the kernel per se, it is propagating that change to all Linux kernels in use -- THAT'S another matter entirely, and is far far more difficult than making sure that a kernel fix is qualified and widely proopagated. Not really, it's just a matter of time. Typical distro cycles are on the order of 3 years. -hpa
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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 able to produce binaries compatible with old kernels for a *long* time for come. Are you honestly saying you'll tell those people "use gcc 4.2 or earlier"? If so, I think most distros will have to freeze gcc for the next several years. -hpa
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 6, 2008 at 9:17 AM, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > 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 able to produce binaries > compatible with old kernels for a *long* time for come. Are you > honestly saying you'll tell those people "use gcc 4.2 or earlier"? If > so, I think most distros will have to freeze gcc for the next several years. > Icc has been following psABI for years on Linux and it doesn't stop people using icc on Linux. On the other hand, it may be a good idea to provide a workaround in gcc and enables it by default. OSVs can fix thekernel and disable it by default. We can even issue a message whenever the workaround is used. H.J.
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 06, 2008 at 01:06:17PM +0100, Richard Guenther wrote: > On 06 Mar 2008 12:45:57 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > > > I suppose one could apply the precautionary principle, but those systems > > that > > > don't update kernels won't update gcc either, so the solution won't work. > > > > You seem to assume that running a gcc 4.3 compiled binary requires a > > gcc update. That is not necessarily true. > > It (sometimes) requires a libgcc and libstdc++ update. "Sometimes" is correct; many users commonly run newer compilers on older distros, with LD_LIBRARY_PATH set to pick up the correct C++ support library. This is particularly common on servers, where you don't want to mess with a working system but you might need to run newer code. So, we've been arguing for a while, so the question is what to do. Using a principle based on the old IETF concept of being liberal in what you accept, and conservative in what you send, I think that both the Linux kernel and gcc should fix the problem. The kernel should fix the information leak, and gcc should remove the assumption that the direction flag is set in a given direction on function entry. The gcc patch will be too late for 4.3.0, but it would be on the 4.3 branch, and we would recommend that distros pick it up for any compilers they ship.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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 used Realia COBOL :-) Another story, the sad story of the intel chip (I think it was the 80188) where Intel made use of Int 5, which was documented as reserved. Unfortunately, Microsoft/IBM had used this for print screen or some such. Intel was absolutely right that their documentation was clear and it was wrong to have used these interrupts .. but the result was a warehouse of unused chips. IBM used it for print screen (and other calls), because Microsoft cassette BASIC used all the non-reserved INT instructions as byte codes (they cut it down to *only* half the interrupt vectors in the disk version.) We're still stuck with the consequences of that hack. -hpa
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 06, 2008 at 03:12:21PM +0100, Olivier Galibert wrote: > On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote: > > Olivier Galibert wrote: > > >On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote: > > >>It's a kernel bug, and it needs to be fixed. > > > > > >I'm not convinced. It's been that way for 15 years, it's that way in > > >the BSD kernels, at that point it's a feature. The bug is in the > > >documentation, nowhere else. And in gcc for blindly trusting the > > >documentation. > > > > No, the bug *in the kernel* was already present (if you had a signal > > raised during a call to memmove). It's just more visible with GCC 4.3. > > I'm curious, since when paper documentation became the Truth and > reality became a bug? If the kernel allows state to leak from one process to another, for example from a process running as root to a process running as an ordinary user, it's a bug, with possible security implications. In this particular case not much can be communicated through a one-bit flag, so it would only be relevant in those situations where you want to forbid any communication channels from a given process. So the kernel developers might consider it a trivial bug. Or, they could just fix it, which I understand is the plan.
Re: GCC 4.3.0 Status Report (2008-03-06)
On Thu, Mar 06, 2008 at 10:56:07AM +0100, Jakub Jelinek wrote: > Status > == > > GCC 4.3.0 release has been tagged in SVN, tarballs uploaded > to gcc.gnu.org (though not to ftp.gnu.org yet). > The branch is still frozen though, until we agree on what if > anything to do about the implied cld instructions on i?86/x86_64. > Hopefully this will not take long. Since tarballs have already hit gcc.gnu.org, we cannot make another release that differs in any way that is also named 4.3.0. It would have to have a different number. People have already spotted and picked up the gcc.gnu.org tarball. We've gone to four-part numbers before in situations like this (2.7.2.1). So it seems that either 4.3.0 stands, or the cld patch (if it is decided that it is urgently needed) would be 4.3.0.1. I suggest just letting 4.3.0 out into the world (finish the release process), and mention the caveat about the cld issue in the announcement. We would then have time to decide whether to do a quick 4.3.0.1, or not.
Re: GCC 4.3.0 Status Report (2008-03-06, 2nd editionOF)
Hi, I'd like to check in the fix for PR target/35189 into gcc 4.3.1: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00729.html It has been approved for 4.3. But I want to give it a little on trunk first. Thanks. H.J. On Thu, Mar 6, 2008 at 9:27 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote: > Status update > = > > The GCC 4.3 branch is now open for commits under normal release branch > rules. > > GCC 4.3.1 should be released earlier than after two months. If we have > the workaround soon, we might cut 4.3.1-rc1 e.g. in two weeks or so, > depending on how well tested it will be then and depending on other changes > on the branch. > > Jakub >
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 06, 2008 at 09:58:41AM -0800, Joe Buck wrote: > If the kernel allows state to leak from one process to another, > for example from a process running as root to a process running as an > ordinary user, it's a bug, with possible security implications. I don't think that it is relevant in your case. If you have the signal handler in something that does not share the VM with the interrupted thread, you will have a context switch which is supposed to store the direction flag and restore the one from the handling thread. If you share the VM there is no context switch but you have access to the exact same memory with the exact same rights, making the leak irrelevant. OG.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Olivier Galibert wrote: On Thu, Mar 06, 2008 at 09:58:41AM -0800, Joe Buck wrote: If the kernel allows state to leak from one process to another, for example from a process running as root to a process running as an ordinary user, it's a bug, with possible security implications. I don't think that it is relevant in your case. If you have the signal handler in something that does not share the VM with the interrupted thread, you will have a context switch which is supposed to store the direction flag and restore the one from the handling thread. If you share the VM there is no context switch but you have access to the exact same memory with the exact same rights, making the leak irrelevant. A process can send a signal via kill. IOW, a malicious process can *control when the process would be interrupted* in order to get it into the signal handler with DF=1. Paolo
Re: GCC 4.3.0 Status Report (2008-03-06)
On Thu, 6 Mar 2008, Joe Buck wrote: > I suggest just letting 4.3.0 out into the world (finish the release > process), and mention the caveat about the cld issue in the announcement. > We would then have time to decide whether to do a quick 4.3.0.1, or not. It certainly does need finishing (e.g. the Bugzilla parts of releasing.html). I think we can just do an early 4.3.1 with whatever other fixes are ready on the branch rather than making a special 4.3.0.1; it's not as if 4.3.0 (or any .0 release) is going to be a widely deployed stable release with people wanting one fix and just that one fix. -- Joseph S. Myers [EMAIL PROTECTED]
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote: > A process can send a signal via kill. IOW, a malicious process can > *control when the process would be interrupted* in order to get it into > the signal handler with DF=1. If the malicious process can send a signal to another process, it could also ptrace() it. Which is more useful, if you wanted to be malicious? Jack
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On 3/6/08, Jack Lloyd <[EMAIL PROTECTED]> wrote: > On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote: > > A process can send a signal via kill. IOW, a malicious process can > > *control when the process would be interrupted* in order to get it into > > the signal handler with DF=1. > > If the malicious process can send a signal to another process, it > could also ptrace() it. Which is more useful, if you wanted to be > malicious? And more to the point, it can happen before GCC 4.3.0. So why does GCC have do something that just happens more often now? I still don't see why we have to work around a bug in the kernel which could show up before GCC 4.3.0. -- Pinski
Some regression numbers
Hello, here are the number of known regressions in GCC 4.3.0 in 4.3 new in 4.3 P1 0 0 P2 9122 P3 27 9 P4 37 6 P5 9620 important 11831 together 25157 Andreas -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
Re: GCC 4.3.0 Status Report (2008-03-06)
On Thu, Mar 06, 2008 at 06:30:46PM +, Joseph S. Myers wrote: > On Thu, 6 Mar 2008, Joe Buck wrote: > > > I suggest just letting 4.3.0 out into the world (finish the release > > process), and mention the caveat about the cld issue in the announcement. > > We would then have time to decide whether to do a quick 4.3.0.1, or not. > > It certainly does need finishing (e.g. the Bugzilla parts of > releasing.html). I think we can just do an early 4.3.1 with whatever > other fixes are ready on the branch rather than making a special 4.3.0.1; > it's not as if 4.3.0 (or any .0 release) is going to be a widely deployed > stable release with people wanting one fix and just that one fix. Sounds good to me; certainly as soon as 4.3.0 gets out and gets wider testing, people will find things. In the past we only used the 4th digit for paper-bag issues (like failure to bootstrap on a major platform or broken release tarballs).
Re: [PATCH][4.3] Deprecate -ftrapv
FX Coudert wrote: In Fortran, integers are used to index arrays. So if you want integer overflow checking, use -fbounds-check :-) I know there is a smiley here, but it seems to me that range checking is quite different from overflow checking. I think what Toon was alluding to is that "real" Fortran programmers don't use integers except for array subscripts. Real life is floating- point based! Well as a one-time real Fortran programmer i would say that comes under the rubric of common misconception. Sure there are lots of fpt operations in Fortran code, but probably most Fortran programs have more integer arithmetic operations than fpt operations, and by no means all are about array indexing :-) I can't remember if Knuth's empirical study of actual Fortran code commented on this situation (that was the study that showed that the average expression in Fortran has only a few terms, unfortunately it is not available unless you pay $30 :-) on the web. FX
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
H. Peter Anvin wrote: 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 engineering viewpoint, but life is not like that. There are lots of copies of Linux kernels around and in use. The issue is not fixing the kernel per se, it is propagating that change to all Linux kernels in use -- THAT'S another matter entirely, and is far far more difficult than making sure that a kernel fix is qualified and widely proopagated. 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.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
H.J. Lu wrote: Icc has been following psABI for years on Linux and it doesn't stop people using icc on Linux. On the other hand, it may be a good idea to provide a workaround in gcc and enables it by default. OSVs can fix thekernel and disable it by default. How widely is icc used? I ask because we have not encocuntered one customer using icc. We have huge numbers of customers using gcc, and many using proprietary compilers from Sun, DEC etc, but never an icc user? We can even issue a message whenever the workaround is used. H.J.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Jack Lloyd wrote: On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote: A process can send a signal via kill. IOW, a malicious process can *control when the process would be interrupted* in order to get it into the signal handler with DF=1. If the malicious process can send a signal to another process, it could also ptrace() it. Which is more useful, if you wanted to be malicious? 1) capabilities(7) 2) sometimes setuid programs send signals (e.g. SIGHUP or SIGUSR1)... Paolo
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
If the malicious process can send a signal to another process, it could also ptrace() it. Which is more useful, if you wanted to be malicious? And more to the point, it can happen before GCC 4.3.0. Yes, and that's why the kernel should just fix it, and the fix should be backported and treated like any other security fix. Paolo
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 06, 2008 at 08:43:27PM +0100, Paolo Bonzini wrote:
> Jack Lloyd wrote:
> >On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
> >>A process can send a signal via kill. IOW, a malicious process can
> >>*control when the process would be interrupted* in order to get it into
> >>the signal handler with DF=1.
> >
> >If the malicious process can send a signal to another process, it
> >could also ptrace() it. Which is more useful, if you wanted to be
> >malicious?
>
> 1) capabilities(7)
Ah you are right, I misinterpreted something from the man page
("non-root processes cannot trace processes that they cannot send
signals to") to mean something it did not (basically, that CAP_KILL
implied CAP_SYS_PTRACE, which from reading the kernel source is
clearly not the case...)
But still: so the threat here is of a malicious process with the
ability to send arbitrary signals to any process using CAP_KILL (since
in any other case when a process can send a signal, it can do much
more damage in other ways), which could leverage that into
(potentially) uid==0 using misexecuted code in a signal handler.
As a correctness issue, obviously this should be fixed/patched around,
if feasible. But as a security flaw? I'm not seeing much that is
compelling.
> 2) sometimes setuid programs send signals (e.g. SIGHUP or SIGUSR1)
I don't understand how this is a problem - unless these setuid
programs, while not malicious, can be tricked into signalling a
process they did not intend to. (In which case they already have a
major bug, df bit being cleared or not).
-Jack
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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 beyond a certain point projects generally accept that they have to monitor their toolchain dependencies. -hpa
Re: [PATCH][4.3] Deprecate -ftrapv
Robert Dewar wrote: FX Coudert wrote: In Fortran, integers are used to index arrays. So if you want integer overflow checking, use -fbounds-check :-) I know there is a smiley here, but it seems to me that range checking is quite different from overflow checking. I think what Toon was alluding to is that "real" Fortran programmers don't use integers except for array subscripts. Real life is floating- point based! Well as a one-time real Fortran programmer i would say that comes under the rubric of common misconception. Sure there are lots of fpt operations in Fortran code, but probably most Fortran programs have more integer arithmetic operations than fpt operations, and by no means all are about array indexing :-) I can't remember if Knuth's empirical study of actual Fortran code commented on this situation (that was the study that showed that the average expression in Fortran has only a few terms, unfortunately it is not available unless you pay $30 :-) on the web. Well, the solution of the question: "Does Fortran require the catching of signed integer overflow" certainly needs the resolution of the question: Does Fortran (the language) require to specify the extent of integers. Well, it doesn't (it is a implementation quality issue). So the issue really becomes: when is integer overflow a quality of implementation issue ? If you can't index arrays with them - therefore, my remark. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/ml/gcc/2008-01/msg9.html
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 6, 2008 at 6:34 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 06, 2008 at 01:06:17PM +0100, Richard Guenther wrote: > > On 06 Mar 2008 12:45:57 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote: > > > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > > > > > I suppose one could apply the precautionary principle, but those > systems that > > > > don't update kernels won't update gcc either, so the solution won't > work. > > > > > > You seem to assume that running a gcc 4.3 compiled binary requires a > > > gcc update. That is not necessarily true. > > > > It (sometimes) requires a libgcc and libstdc++ update. > > "Sometimes" is correct; many users commonly run newer compilers on older > distros, with LD_LIBRARY_PATH set to pick up the correct C++ support > library. This is particularly common on servers, where you don't want to > mess with a working system but you might need to run newer code. > > So, we've been arguing for a while, so the question is what to do. > > Using a principle based on the old IETF concept of being liberal in what > you accept, and conservative in what you send, I think that both the Linux > kernel and gcc should fix the problem. The kernel should fix the > information leak, and gcc should remove the assumption that the direction > flag is set in a given direction on function entry. > > The gcc patch will be too late for 4.3.0, but it would be on the 4.3 > branch, and we would recommend that distros pick it up for any compilers > they ship. 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. Richard.
Re: GCC 4.3.0 Status Report (2008-03-06)
On Thu, Mar 6, 2008 at 8:09 PM, Joe Buck <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 06, 2008 at 06:30:46PM +, Joseph S. Myers wrote: > > On Thu, 6 Mar 2008, Joe Buck wrote: > > > > > I suggest just letting 4.3.0 out into the world (finish the release > > > process), and mention the caveat about the cld issue in the announcement. > > > We would then have time to decide whether to do a quick 4.3.0.1, or not. > > > > It certainly does need finishing (e.g. the Bugzilla parts of > > releasing.html). I think we can just do an early 4.3.1 with whatever > > other fixes are ready on the branch rather than making a special 4.3.0.1; > > it's not as if 4.3.0 (or any .0 release) is going to be a widely deployed > > stable release with people wanting one fix and just that one fix. > > Sounds good to me; certainly as soon as 4.3.0 gets out and gets wider > testing, people will find things. In the past we only used the 4th digit > for paper-bag issues (like failure to bootstrap on a major platform or > broken release tarballs). Heh, we even did a quick 3.2 release after fixing ABI issues in 3.1. Richard.
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
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 option will help embedded vendors who can guarantee that it's not a problem. -hpa
Re: GCC 4.3.0 Status Report (2008-03-06)
On Thu, 6 Mar 2008, Richard Guenther wrote: > > Sounds good to me; certainly as soon as 4.3.0 gets out and gets wider > > testing, people will find things. In the past we only used the 4th digit > > for paper-bag issues (like failure to bootstrap on a major platform or > > broken release tarballs). > > Heh, we even did a quick 3.2 release after fixing ABI issues in 3.1. Which I consider to be a mistake (the idea was that 3.2 would conform to the C++ ABI, but further bugs were found later). The next deliberate C++ ABI change can hopefully happen whenever we find it necessary to bump the libstdc++ soname. -- Joseph S. Myers [EMAIL PROTECTED]
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Jack Lloyd wrote: > But still: so the threat here is of a malicious process with the > ability to send arbitrary signals to any process using CAP_KILL (since > in any other case when a process can send a signal, it can do much > more damage in other ways), which could leverage that into > (potentially) uid==0 using misexecuted code in a signal handler. > > As a correctness issue, obviously this should be fixed/patched around, > if feasible. But as a security flaw? I'm not seeing much that is > compelling. > >> 2) sometimes setuid programs send signals (e.g. SIGHUP or SIGUSR1) > > I don't understand how this is a problem - unless these setuid > programs, while not malicious, can be tricked into signalling a > process they did not intend to. (In which case they already have a > major bug, df bit being cleared or not). think apps keeping crypto keys etc in ram and wiping them from signal handlers. eg gnupg does this; fortunately it seems to have moved from memset() to a open coded solution, so probably isn't affected. OTOH it wouldn't surprise me these days if the compiler would emit string ops even w/o an explicit mem* call. Copying a private memory region to some public buffer could also lead to interesting results... IOW being able to avoid a memset (or copying the wrong data) certainly could have security consequences. artur
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote: > 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 option will help embedded vendors who can guarantee that it's not a > problem. For very very low values of "help". To be realistic it is very unlikely anybody will measure a difference from a few more or a few less clds in a program. It's not that they're expensive instructions and they normally don't happen in inner loops either. "If you enable this option you will get an optimization that you cannot measure" @) -Andi
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Thu, Mar 6, 2008 at 11:06 PM, Andi Kleen <[EMAIL PROTECTED]> wrote: > > On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote: > > 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 option will help embedded vendors who can guarantee that it's not a > > problem. > > For very very low values of "help". > > To be realistic it is very unlikely anybody will measure a difference > from a few more or a few less clds in a program. It's not that they're > expensive instructions and they normally don't happen in inner loops either. > > "If you enable this option you will get an optimization that you cannot > measure" @) Which is probably true for most of GCCs options. Oh wait - you can measure the effect on compile-time and compile-time memory usage! :) ... *runs*
gcc-4.3-20080306 is now available
Snapshot gcc-4.3-20080306 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080306/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 132992 You'll find: gcc-4.3-20080306.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080306.tar.bz2 C front end and core compiler gcc-ada-4.3-20080306.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080306.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080306.tar.bz2 C++ front end and runtime gcc-java-4.3-20080306.tar.bz2 Java front end and runtime gcc-objc-4.3-20080306.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080306.tar.bz2The GCC testsuite Diffs from 4.3-20080228 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: atomic accesses
On 3/5/08, Andrew Haley <[EMAIL PROTECTED]> wrote: > The proposed memory model partly described at > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2492.html > http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2176.html > shows the way the C++ committee is moving. This involves explicit > atomic operations. The C++0x standard has formally incorporated the new memory model and atomic operations into the current working draft for the standard: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2521.pdf As this standard has not been approved, it may change, but significant changes are unlikely. I think gcc would be better served by implementing the standard than by trying to define a different model, both because getting such models right is hard and because multiple models make life hard for the programmers that must code to multiple platforms. -- Lawrence Crowl
C++ FE question: When is CLASSTYPE_VBASECLASSES valid?
Hi, I have a question about the validity of CLASSTYPE_VBASECLASSES. Due to templates, it is not possible to know if a class has virtual bases or not until the class is fully instantiated. Is checking processing_template_decl sufficient to guarantee that CLASSTYPE_VBASECLASSES is valid? Thanks. -Doug
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
On Mar 6, 2008, at 2:06 PM, Andi Kleen wrote: On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote: 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 option will help embedded vendors who can guarantee that it's not a problem. For very very low values of "help". To be realistic it is very unlikely anybody will measure a difference from a few more or a few less clds in a program. It's not that they're expensive instructions They aren't? According to http://www.agner.org/optimize/instruction_tables.pdf , they have a latency of 52 cycles on at least one popular x86 chip. -Chris
Seg fault in call_gmon_start
I just compiled an app with GCC. It is segmentation faulting in call_gmon_start
(even before reaching main() of my program
What does call_gmon_start() do ? Which library defines this function?
gdb) where
#0 0x2a000750 in call_gmon_start ()
#1 0x in ?? ()
(gdb) info
(gdb) disassemble call_gmon_start
Dump of assembler code for function call_gmon_start:
0x2a000750 : str r10, [sp, #-4]!
0x2a000754 : ldr r10, [pc, #32] ; 0x2a00077c
0x2a000758 : ldr r3, [pc, #32] ; 0x2a000780
0x2a00075c : add r10, pc, r10
0x2a000760 : ldr r2, [r10, r3]
0x2a000764 : cmp r2, #0 ; 0x0
0x2a000768 : beq 0x2a000774
0x2a00076c : ldmia sp!, {r10}
0x2a000770 : b 0x2a000744 <_init+100>
0x2a000774 : ldmia sp!, {r10}
0x2a000778 : bx lr
0x2a00077c : andeq r8, r0, r0, ror #9
0x2a000780 : andeq r0, r0, r12, lsr #32
End of assembler dump.
Re: Injecting data declarations?
Reuben Harris wrote: I would like to modify GCC to inject a link-once word-sized data declaration into the object file, i.e. to behave AS IF there were extra declarations in the source code, e.g.: Builtin functions are a good source for how to create decls, but they create mostly type decls. See for instance c_register_builtin_type in c-common.c. The profilers are another good choice, and they create variables. See for instance tree_init_ic_make_global_vars in tree-profile.c. These aren't link-once variables though. I think all you need for that is a call to make_decl_one_only, but you might want to look for examples. Jim
Re: Patch: delete treelang
I'm cc-ing gcc@ & gcc-patches@ list. I feel this interesting discussion
belongs more to gcc@
Tim Josling wrote:
Treelang was based on Richard Kenner's toy language. I packaged it up to
include as a part of GCC because toy had fallen behind the GCC mainline
and no longer worked, and there were various versions floating around
that were all broken in different ways. When I re-started work on my
COBOL compiler again a few months ago, I was very pleased to see
treelang still there because it will make my job of rebuilding an
interface to the GCC back end a lot easier.
I suspect that people who have worked on GCC full time for a number of
years, and who have commit authority, can tend to forget the many
obstacles that are in front of someone starting work on GCC,
particularly on a front end.
I really agree with that. We usually do not have enough in mind that GCC
is a particularily difficult open source software to dive into. And this
is a major bottleneck to attract new developers & maintainers.
Issues are not only on the front end. It is also difficult to interest
people to work on the middle end, and perhaps even on the back end.
FWIW, I'm also trying to attract some new people & companies to work on
GCC within european projects, and it is a very difficult job (even with
the perspective of partial funding with european taxpayers' money).
The impediments to starting work on GCC, particularly building a front
end, are formidable. Treelang was an attempt to somewhat reduce those
impediments. In particular the front end documentation has traditionally
been considerably more limited than the documentation for the rest of
GCC.
I would say the same for the middle-end also, and also for
infrastructure stuff. Even the building part of GCC (eg Makefile.in and
configure.ac are very intimidating).
The main front ends also tend to fractally mix language-specific
code with the generic GCC back end interface which makes it much harder
to understand what the essentials are and to use one as a starting
point.
It is very difficult to be fair and well informed, but I have the
impression that GCC is more difficult to dive into than perhaps other
similar monster open source (= free GPL-ed software) projects.
I tend to believe that we the GCC community should make diving into GCC
easier, even if I don't understand how to do that. I really think that
GCC is still lacking of developers (& developping efforts), and that its
current state (which is remarkable for a 20+ years software) make it too
intimidating for many potential developers.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
