Re: [08/08] uml: va_copy fix
On Thursday 07 April 2005 11:16, Renate Meijer wrote: > On Apr 6, 2005, at 9:09 PM, Blaisorblade wrote: > > Btw: I've not investigated which one of the two behaviours is the > > buggy one - > > if you know, maybe you or I can report it. > > From a strict ISO-C point of view, both are. It's a gcc-specific > "feature" which (agreed) does come in handy sometimes. Well, for "range" assignments GCC mustn't complain, but for the rest the double assignment laziness is not very useful. Could they at least add a -Wsomething inside -Wall or -W for this problem? > However it makes > it quite hard to say which is the buggy version, since the > "appropriate" behavior > is a question of definition (by the gcc-folks). They may even argue > that, having changed their minds about it, neither is buggy, but both > conform to the specifications (for that specific functionality). > > That's pretty much the trouble with relying on gcc-extensions: since > there's no standard, it's difficult to tell what's wrong and what's > right. I'll dive into it. > > Regards, > > Renate Meijer. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [08/08] uml: va_copy fix
On Apr 6, 2005, at 9:09 PM, Blaisorblade wrote:
For Jörn Engel and the issue he opened: at the end of this mail I
describe
another bug caught by 2.95 and not by 3.x.
On Tuesday 05 April 2005 22:18, Renate Meijer wrote:
On Apr 5, 2005, at 8:53 PM, Blaisorblade wrote:
On Tuesday 05 April 2005 20:47, Renate Meijer wrote:
On Apr 5, 2005, at 6:48 PM, Greg KH wrote:
The use of '__' violates compiler namespace.
Why? The symbol is defined by the compiler itself.
If a function is prefixed with a double underscore, this implies the
function is internal to
the compiler, and may change at any time, since it's not governed by
some sort of standard.
Hence that code may start suffering from bitrot and complaining to the
compiler guys won't help.
They'll just tell you to RTFM.
Ok, agreed in general. However, the -stable tree is for "current" GCC.
Your
objections would better refer to the fact that the same patch has
already
been merged into the main trunk.
Also, they have no point in doing this, probably. And the __va_copy
name was
used in the draft C99 standard so it's widespread (I've read this on
"man 3
va_copy").
If 2.95.4 were not easily
replaced by
a much better version (3.3.x? 3.4.x) I would see a reason to
disregard
this, but a fix
merely to satisfy an obsolete compiler?
Let's not flame, Linus Torvalds said "we support GCC 2.95.3, because
the newer
versions are worse compilers in most cases".
You make it sound as if you were reciting Ye Holy Scribings. When did
Linus Thorvalds say this? In the Redhat-2.96 debacle? Before or after
3.3? I have searched for that quote,
Sorry for the quote marks, it was a resume of what he said (and from
re-reading, it's still a correct resume).
but could not find it, and having
suffered under 3.1.1, I can well understand his wearyness for the
earlier versions.
I've read the same kerneltrap article you quote.
See
http://kerneltrap.org/node/4126, halfway down.
Ok, read.
For the cold, hard facts...
http://www.suse.de/~aj/SPEC/
Linus pointed out that SPEC performances are not a good test case for
the
kernel compilation in that article. Point out a kernel compilation
case.
Consider me as having no opinion on this except not wanting to break
on purpose Debian users.
If Debian users are stuck with a pretty outdated compiler, i'd
seriously suggest migrating to some
other distro which allows more freedom.
I guess they can, if they want, upgrade some selected packages from
newer
trees, maybe by recompiling (at least, on Gentoo it's trivial, maybe
on a
binary distro like Debian it's harder).
On a binary distro they can recompile, too. Althoughg i'll admit it's
not something
a newbie should do.
If linux itself is holding them
back, there's a need for some serious patching.
If there are serious
issues in the gcc compiler, which hinder migration to a more
up-to-date
version our efforts should be directed at solving them in that
project,
not this.
Linus spoke about the compiler speed, which isn't such a bad reason.
It may be a reason for folks who do a lot of development. But that can
hardly serve
as a "main" reason. Speed of compilation, after all, is a one-time
thing. Howver, as i've
understood, there are more pressing reasons.
He's
unfair in saying that GCC 3.x does not optimize better than older
releases,
probably; I guess that the compilation flags (I refer to
-fno-strict-aliasing, which disables some optimizations) make some
difference, as do the memory barriers (as pointed in the comments).
If you want, submit a patch removing Gcc 2.95.3 from supported
versions, and get ready to fight
for it (and probably loose).
I don't fight over things like that, i'm not interested in politics. I
merely point out the problem. And yes.
I do think support for obsolete compiler should be dumped in favor of
a
more modern version. Especially if that compiler requires invasions of
compiler-namespace. The patch, as presented, is not guaranteed to be
portable over versions, and may thus introduce another problem with
future versions of GCC.
When and if that will happen, I'll come with an hack.
Ok. And a couple of hacks down the road, and the code will look nice
and cryptic and a newbie trying to understand what's going on, will
have a nice set of puzzles to solve.
UML already has need for some GCC - version specific behaviour
(see arch/um/kernel/gmon_syms.c on a recent BitKeeper snapshot,
even -rc1-bk5 has this code).
Perhaps. But i think you'll agree it's not "The way to go".
Also, that GCC has discovered some syscall table errors in UML - I
sent a
separate patch, which was a bit big sadly (in the reduced version,
about 70
lines + description).
I am not quite sure what is intended here... Please explain.
I'm reattaching the patch, so that you can look at the changelog (I'm
also
resending it as a separate email so that it is reviewed and possibly
merged).
Basically this is an error in GCC 2 and not in GCC 3:
int [] list = {
[0] = 1,
[0] = 1
}
(I've not tested the abov
Re: [08/08] uml: va_copy fix
On Wed, 6 April 2005 21:09:50 +0200, Blaisorblade wrote:
>
> I'm reattaching the patch, so that you can look at the changelog (I'm also
> resending it as a separate email so that it is reviewed and possibly merged).
> Basically this is an error in GCC 2 and not in GCC 3:
>
> int [] list = {
> [0] = 1,
> [0] = 1
> }
> (I've not tested the above itself, but this should be a stripped down version
> of one of the bugs fixed in the patch).
>
> That sort of code in the UML syscall table is not the safer one - in fact,
> apart this patch for the stable tree, I'm refactoring the UML syscall table
> completely (for 2.6.12 / 2.6.13).
>
> Btw: I've not investigated which one of the two behaviours is the buggy one -
> if you know, maybe you or I can report it.
Your code is at best redundant. And I'd bet beer that it is not what
its author intended to write. So the bug is in GCC 3, imo.
Jörn
--
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [08/08] uml: va_copy fix
On Wednesday 06 April 2005 14:04, Renate Meijer wrote: > On Apr 6, 2005, at 1:32 PM, Jörn Engel wrote: > > On Tue, 5 April 2005 22:18:26 +0200, Renate Meijer wrote: > > > > You did read include/linux/compiler.h, didn't you? > So instead of applying this patch, simply > > #ifdef VERSION_MINOR < WHATEVER > #define va_copy __va_copy > #endif > > in include/linux/compiler_gcc2.h > > Thus solving the problem without having to invade compiler namespace all > over the place, but doing so in *one* place only. About this one: thanks for suggesting this and being constructive, I'll do ASAP (if I don't forget) this for the -bk tree. However, I think that Greg KH for the stable tree would prefer a local tested patch rather than a global one with possible side effects, right Greg? Also, I hope this discussion does not count as a vote for the -stable tree inclusion (since dropping GCC 2 support in the -stable tree is exactly the purpose of this tree, right ;-) ? ). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [08/08] uml: va_copy fix
For Jörn Engel and the issue he opened: at the end of this mail I describe
another bug caught by 2.95 and not by 3.x.
On Tuesday 05 April 2005 22:18, Renate Meijer wrote:
> On Apr 5, 2005, at 8:53 PM, Blaisorblade wrote:
> > On Tuesday 05 April 2005 20:47, Renate Meijer wrote:
> >> On Apr 5, 2005, at 6:48 PM, Greg KH wrote:
> >> The use of '__' violates compiler namespace.
> >
> > Why? The symbol is defined by the compiler itself.
> If a function is prefixed with a double underscore, this implies the
> function is internal to
> the compiler, and may change at any time, since it's not governed by
> some sort of standard.
> Hence that code may start suffering from bitrot and complaining to the
> compiler guys won't help.
> They'll just tell you to RTFM.
Ok, agreed in general. However, the -stable tree is for "current" GCC. Your
objections would better refer to the fact that the same patch has already
been merged into the main trunk.
Also, they have no point in doing this, probably. And the __va_copy name was
used in the draft C99 standard so it's widespread (I've read this on "man 3
va_copy").
> >> If 2.95.4 were not easily
> >> replaced by
> >> a much better version (3.3.x? 3.4.x) I would see a reason to disregard
> >> this, but a fix
> >> merely to satisfy an obsolete compiler?
> >
> > Let's not flame, Linus Torvalds said "we support GCC 2.95.3, because
> > the newer
> > versions are worse compilers in most cases".
> You make it sound as if you were reciting Ye Holy Scribings. When did
> Linus Thorvalds say this? In the Redhat-2.96 debacle? Before or after
> 3.3? I have searched for that quote,
Sorry for the quote marks, it was a resume of what he said (and from
re-reading, it's still a correct resume).
> but could not find it, and having
> suffered under 3.1.1, I can well understand his wearyness for the
> earlier versions.
I've read the same kerneltrap article you quote.
> See
>
> http://kerneltrap.org/node/4126, halfway down.
Ok, read.
> For the cold, hard facts...
>
> http://www.suse.de/~aj/SPEC/
Linus pointed out that SPEC performances are not a good test case for the
kernel compilation in that article. Point out a kernel compilation case.
>
>
> > Consider me as having no opinion on this except not wanting to break
> > on purpose Debian users.
>
> If Debian users are stuck with a pretty outdated compiler, i'd
> seriously suggest migrating to some
> other distro which allows more freedom.
I guess they can, if they want, upgrade some selected packages from newer
trees, maybe by recompiling (at least, on Gentoo it's trivial, maybe on a
binary distro like Debian it's harder).
> If linux itself is holding them
> back, there's a need for some serious patching.
> If there are serious
> issues in the gcc compiler, which hinder migration to a more up-to-date
> version our efforts should be directed at solving them in that project,
> not this.
Linus spoke about the compiler speed, which isn't such a bad reason. He's
unfair in saying that GCC 3.x does not optimize better than older releases,
probably; I guess that the compilation flags (I refer to
-fno-strict-aliasing, which disables some optimizations) make some
difference, as do the memory barriers (as pointed in the comments).
> > If you want, submit a patch removing Gcc 2.95.3 from supported
> > versions, and get ready to fight
> > for it (and probably loose).
> I don't fight over things like that, i'm not interested in politics. I
> merely point out the problem. And yes.
> I do think support for obsolete compiler should be dumped in favor of a
> more modern version. Especially if that compiler requires invasions of
> compiler-namespace. The patch, as presented, is not guaranteed to be
> portable over versions, and may thus introduce another problem with
> future versions of GCC.
When and if that will happen, I'll come with an hack. UML already has need for
some GCC - version specific behaviour (see arch/um/kernel/gmon_syms.c on a
recent BitKeeper snapshot, even -rc1-bk5 has this code).
> > Also, that GCC has discovered some syscall table errors in UML - I
> > sent a
> > separate patch, which was a bit big sadly (in the reduced version,
> > about 70
> > lines + description).
> I am not quite sure what is intended here... Please explain.
I'm reattaching the patch, so that you can look at the changelog (I'm also
resending it as a separate email so that it is reviewed and possibly merged).
Basically this is an error in GCC 2 and not in GCC 3:
int [] list = {
[0] = 1,
[0] = 1
}
(I've not tested the above itself, but this should be a stripped down version
of one of the bugs fixed in the patch).
That sort of code in the UML syscall table is not the safer one - in fact,
apart this patch for the stable tree, I'm refactoring the UML syscall table
completely (for 2.6.12 / 2.6.13).
Btw: I've not investigated which one of the two behaviours is the buggy one -
if you know, maybe you or I can report it.
> timeo hominem unius libri
Re: [stable] Re: [08/08] uml: va_copy fix
On Wed, 6 April 2005 19:58:06 +0200, Renate Meijer wrote: > On Apr 6, 2005, at 7:33 PM, Jörn Engel wrote: > >On Wed, 6 April 2005 19:29:46 +0200, Renate Meijer wrote: > >> > >>I think its worth the time and trouble to take this up with the gcc > >>crowd. So if you could provide a list of things 3.3 misses, i'm sure > >>the gcc-crowd would like it. > > > >If you volunteer to do work with the gcc-crowd, I can dig up some old > >stuff and send you testcases. Sure. > > I'll volunteer. [...] Thanks! > Problem is, i'll be spending 5 weeks prety much scattered around > europe, [...] Have fun! Ok, here is the first testcase. It was a real bug, even though never submitted to Linus: #define ASM_MACRO \ op; \ #ifdef FOO \ op; \ #else \ op; \ #endif \ op; \ op; The thing occurred in some entry.S or head.S, don't remember exactly which one. Gcc people might tell you unfriendly things about using the _C_ preprocessor for _ASM_ code, but that's just how the kernel code is written. With gcc 2.95, the old preprocessor errored out on the correct line and we had a look at the code. With 3.x, preprocessor chewed things and starting from "#ifdef", everything was interpreted as a comment and ignored. Code never worked and the real bug was papered over by more ugliness, but stayed that way for a year until someone (me) tried to compile it with 2.95. Jörn -- You cannot suppose that Moliere ever troubled himself to be original in the matter of ideas. You cannot suppose that the stories he tells in his plays have never been told before. They were culled, as you very well know. -- Andre-Louis Moreau in Scarabouche - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] Re: [08/08] uml: va_copy fix
On Apr 6, 2005, at 7:33 PM, Jörn Engel wrote: On Wed, 6 April 2005 19:29:46 +0200, Renate Meijer wrote: I think its worth the time and trouble to take this up with the gcc crowd. So if you could provide a list of things 3.3 misses, i'm sure the gcc-crowd would like it. If you volunteer to do work with the gcc-crowd, I can dig up some old stuff and send you testcases. Sure. I'll volunteer. As I said, i think it's worth the time and trouble. But i can't do it on my own, at least i need some backup from thee development community around here. You telling me what's up, for one. I found one mail by Greg KH spelling out some of the problems, but you suggest there's more to worry about. Problem is, i'll be spending 5 weeks prety much scattered around europe, starting next friday and have no idea on my online-ness yet. As it is, my trusty mac is my only digital companion, and my linux-box is in storage for the time being. So don't expect any results before May 17. But hey... Somebody has to do it. Just don't be surprised if the folks at gcc do not agree with you "a prima vista". They may have a different idea on what exactly constitutes a bug. Upside is, i'll be taking my Mac anyway, so at least i'll have the sources handy. I'll start downloading tonight, so if you have data, please, lets have it. Nevertheless, the points made in previous posts stand. Regards, Renate Meijer. -- timeo hominem unius libri Thomas van Aquino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] Re: [08/08] uml: va_copy fix
On Wed, 6 April 2005 19:29:46 +0200, Renate Meijer wrote: > > I think its worth the time and trouble to take this up with the gcc > crowd. So if you could provide a list of things 3.3 misses, i'm sure > the gcc-crowd would like it. If you volunteer to do work with the gcc-crowd, I can dig up some old stuff and send you testcases. Sure. Jörn -- The strong give up and move away, while the weak give up and stay. -- unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] Re: [08/08] uml: va_copy fix
On Apr 6, 2005, at 5:46 PM, Greg KH wrote: On Wed, Apr 06, 2005 at 02:27:51PM +0200, J?rn Engel wrote: Is it worth the effort? Not sure. But the "it's old, drop support for it" argument just doesn't cut it and it doesn't get any better by repetition. However, the argument gets better every time "a workaround" is needed. If there are still serious issues open (like a failure to catch bugs the old version did), they are issues which need resolving in the compiler. Patching the wrong project, is introducing two imperfections. I think its worth the time and trouble to take this up with the gcc crowd. So if you could provide a list of things 3.3 misses, i'm sure the gcc-crowd would like it. Exactly, that's why this patch is valid. At the very least, it's at the wrong place, since it should be patched in ./include/linux/compiler.h. And I do not exactly argue "it's old, drop support for it", but rely on the "dont rely on compiler internals or at least stick them on one place where everyone can find them easily, instead of peppering the entire codebase with them" argument. Regards, Renate Meijer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] Re: [08/08] uml: va_copy fix
On Wed, Apr 06, 2005 at 02:27:51PM +0200, J?rn Engel wrote: > > Is it worth the effort? Not sure. But the "it's old, drop support > for it" argument just doesn't cut it and it doesn't get any better by > repetition. Exactly, that's why this patch is valid. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [08/08] uml: va_copy fix
On Wed, 6 April 2005 14:04:39 +0200, Renate Meijer wrote: > > >And you did read this thread as well, right? > >http://kerneltrap.org/node/4126 > > > Things seem to have improved a bit lately. The gcc-3.x series was > basically not worth it for plain C until 3.3 or so. > > > Yes. You did read the actual data as produced by that guy from Suse, > did you? In the past, > people may have justly stuck to (e.g.) 2.95.3, however, support for > that version now starts to > require dependencies on compiler internals. This is one argument in > favor of dropping support > for that version, or at least not to spread compiler dependent stuff > all over the code. Fyi, another fact that was missing from the quoted thread: gcc 2.95 catches bugs that 3.x compilers simply miss. Support for the old compiler is more work, no doubt, and at times requires to work around plain compiler bugs as well. But there is some return on investment. Is it worth the effort? Not sure. But the "it's old, drop support for it" argument just doesn't cut it and it doesn't get any better by repetition. Jörn -- Schrödinger's cat is not dead. -- Illiad - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [08/08] uml: va_copy fix
On Apr 6, 2005, at 1:32 PM, Jörn Engel wrote: On Tue, 5 April 2005 22:18:26 +0200, Renate Meijer wrote: If a function is prefixed with a double underscore, this implies the function is internal to the compiler, and may change at any time, since it's not governed by some sort of standard. Hence that code may start suffering from bitrot and complaining to the compiler guys won't help. You did read include/linux/compiler.h, didn't you? Yes. It seems a good place to hide compiler-internal stuff as the one this patch implements. And I know linux does not exactly have a great track record on this issue. But just because the dependency is there, does not imply it is a GOOD THING to have it. So instead of applying this patch, simply #ifdef VERSION_MINOR < WHATEVER #define va_copy __va_copy #endif in include/linux/compiler_gcc2.h Thus solving the problem without having to invade compiler namespace all over the place, but doing so in *one* place only. And you did read this thread as well, right? http://kerneltrap.org/node/4126 Things seem to have improved a bit lately. The gcc-3.x series was basically not worth it for plain C until 3.3 or so. Yes. You did read the actual data as produced by that guy from Suse, did you? In the past, people may have justly stuck to (e.g.) 2.95.3, however, support for that version now starts to require dependencies on compiler internals. This is one argument in favor of dropping support for that version, or at least not to spread compiler dependent stuff all over the code. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [08/08] uml: va_copy fix
On Tue, 5 April 2005 22:18:26 +0200, Renate Meijer wrote: > > If a function is prefixed with a double underscore, this implies the > function is internal to > the compiler, and may change at any time, since it's not governed by > some sort of standard. > Hence that code may start suffering from bitrot and complaining to the > compiler guys won't help. You did read include/linux/compiler.h, didn't you? And you did read this thread as well, right? http://kerneltrap.org/node/4126 Jörn -- Time? What's that? Time is only worth what you do with it. -- Theo de Raadt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [08/08] uml: va_copy fix
On Apr 5, 2005, at 8:53 PM, Blaisorblade wrote: On Tuesday 05 April 2005 20:47, Renate Meijer wrote: On Apr 5, 2005, at 6:48 PM, Greg KH wrote: -stable review patch. If anyone has any objections, please let us know. -- Uses __va_copy instead of va_copy since some old versions of gcc (2.95.4 for instance) don't accept va_copy. Are there many kernels still being built with 2.95.4? It's quite antiquated, as far as i'm aware. The use of '__' violates compiler namespace. Why? The symbol is defined by the compiler itself. If a function is prefixed with a double underscore, this implies the function is internal to the compiler, and may change at any time, since it's not governed by some sort of standard. Hence that code may start suffering from bitrot and complaining to the compiler guys won't help. They'll just tell you to RTFM. If 2.95.4 were not easily replaced by a much better version (3.3.x? 3.4.x) I would see a reason to disregard this, but a fix merely to satisfy an obsolete compiler? Let's not flame, Linus Torvalds said "we support GCC 2.95.3, because the newer versions are worse compilers in most cases". You make it sound as if you were reciting Ye Holy Scribings. When did Linus Thorvalds say this? In the Redhat-2.96 debacle? Before or after 3.3? I have searched for that quote, but could not find it, and having suffered under 3.1.1, I can well understand his wearyness for the earlier versions. See http://kerneltrap.org/node/4126, halfway down. For the cold, hard facts... http://www.suse.de/~aj/SPEC/ Consider me as having no opinion on this except not wanting to break on purpose Debian users. If Debian users are stuck with a pretty outdated compiler, i'd seriously suggest migrating to some other distro which allows more freedom. If linux itself is holding them back, there's a need for some serious patching. If there are serious issues in the gcc compiler, which hinder migration to a more up-to-date version our efforts should be directed at solving them in that project, not this. If you want, submit a patch removing Gcc 2.95.3 from supported versions, and get ready to fight for it (and probably loose). I don't fight over things like that, i'm not interested in politics. I merely point out the problem. And yes. I do think support for obsolete compiler should be dumped in favor of a more modern version. Especially if that compiler requires invasions of compiler-namespace. The patch, as presented, is not guaranteed to be portable over versions, and may thus introduce another problem with future versions of GCC. Also, that GCC has discovered some syscall table errors in UML - I sent a separate patch, which was a bit big sadly (in the reduced version, about 70 lines + description). I am not quite sure what is intended here... Please explain. timeo hominem unius libri Thomas van Aquino - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [08/08] uml: va_copy fix
On Tuesday 05 April 2005 20:47, Renate Meijer wrote: > On Apr 5, 2005, at 6:48 PM, Greg KH wrote: > > -stable review patch. If anyone has any objections, please let us > > know. > > > > -- > > > > Uses __va_copy instead of va_copy since some old versions of gcc > > (2.95.4 > > for instance) don't accept va_copy. > > Are there many kernels still being built with 2.95.4? It's quite > antiquated, as far as > i'm aware. > > The use of '__' violates compiler namespace. Why? The symbol is defined by the compiler itself. > If 2.95.4 were not easily > replaced by > a much better version (3.3.x? 3.4.x) I would see a reason to disregard > this, but a fix > merely to satisfy an obsolete compiler? Let's not flame, Linus Torvalds said "we support GCC 2.95.3, because the newer versions are worse compilers in most cases". One user complained, even because he uses Debian, and I cannot do less than make sure that we comply with the requirements we have choosen (compiling with that GCC). Please let's not start a flame on this. Consider me as having no opinion on this except not wanting to break on purpose Debian users. If you want, submit a patch removing Gcc 2.95.3 from supported versions, and get ready to fight for it (and probably loose). Also, that GCC has discovered some syscall table errors in UML - I sent a separate patch, which was a bit big sadly (in the reduced version, about 70 lines + description). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [08/08] uml: va_copy fix
On Apr 5, 2005, at 6:48 PM, Greg KH wrote: -stable review patch. If anyone has any objections, please let us know. -- Uses __va_copy instead of va_copy since some old versions of gcc (2.95.4 for instance) don't accept va_copy. Are there many kernels still being built with 2.95.4? It's quite antiquated, as far as i'm aware. The use of '__' violates compiler namespace. If 2.95.4 were not easily replaced by a much better version (3.3.x? 3.4.x) I would see a reason to disregard this, but a fix merely to satisfy an obsolete compiler? In my humblest of opinions you are fixing a bug that is better solved by downloading a more recent version of gcc. Regards, Renate Meijer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[08/08] uml: va_copy fix
-stable review patch. If anyone has any objections, please let us know. -- Uses __va_copy instead of va_copy since some old versions of gcc (2.95.4 for instance) don't accept va_copy. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- clean-linux-2.6.11-paolo/arch/um/kernel/skas/uaccess.c |3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) diff -puN arch/um/kernel/skas/uaccess.c~uml-va_copy_fix arch/um/kernel/skas/uaccess.c --- clean-linux-2.6.11/arch/um/kernel/skas/uaccess.c~uml-va_copy_fix 2005-04-01 22:37:11.0 +0200 +++ clean-linux-2.6.11-paolo/arch/um/kernel/skas/uaccess.c 2005-04-01 22:37:11.0 +0200 @@ -61,7 +61,8 @@ static void do_buffer_op(void *jmpbuf, v void *arg; int *res; - va_copy(args, *(va_list *)arg_ptr); + /* Some old gccs recognize __va_copy, but not va_copy */ + __va_copy(args, *(va_list *)arg_ptr); addr = va_arg(args, unsigned long); len = va_arg(args, int); is_write = va_arg(args, int); _ ___ stable mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/stable - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
