Re: char should be signed by default
A given program is written in one or the other of these two dialects. The program stands a chance to work on most any machine if it is compiled with the proper dialect. It is unlikely to work at all if compiled with the wrong dialect. It depends on the program, and whether or not chars in the user's character set is sign extended (ie, in the USA, you likely won't notice a difference between the two if chars just hold character values). You might notice if a -1 (EOF) becomes a 255 and you get an infinite loop in return (it did bite me). Of course, this is a bug in that outside the US a 255 character might become an EOF. Paolo
Re: [RFC] Our release cycles are getting longer
[sorry for breaking the thread; stupid gmail doesn't want to add custom References headers] It may be that not too many people pick up 4.2.0. But, if 4.3 isn't looking very stable, there will be a point when people decide that 4.2.0 is looking very attractive. The worst outcome of trying to do a 4.2.0 release is that we'll fix some things that are also bugs in 4.3; most 4.2 bugs are also in 4.3. From the Fortran point of view, and however limited it might be, skipping the 4.2.0 release would be very unfortunate. We've been working hard on it, and especially in recent time, many bug fixes have been deemed to risky to backport to the 4.1 branch. 4.3 is still a long way down the road, and the 4.2 branch has interesting features even from the non-Fortran point of view. About the other points of the discussion, maybe getting more exposure for the mainline branch (4.3.0) could get us more feedback? People are more involved in fixing bugs when they come just after their patch commit than when the report comes one month after. (and I can thing of examples in our bugzilla that confort this view :) Now, how to get greater exposure? We (some of the gfortran maintainers) have been making available regular binaries of the compiler for common archs; most of the bug reports are made from people using these binaries, so I suppose it's a way that works for us. There are a few people that help with gfortran development, not by patching, but by testing/filing detailed bug reports/writing testcases/etc. (They even tend to get involved in gfortran patching at some point :) Can it work for GCC as a whole? Maybe not for all types of bugs and users (the Fortran users mostly have mainstream archs), but we could nonetheless use more feedback and maybe have more people testing their apps with the latest mainline state. Sorry for being so long, but maybe the gfortran experience can help here, FX
Re: [OT] char should be signed by default
On Thu, Jan 25, 2007 at 10:29:29AM +0100, Paolo Bonzini wrote:
>
> >>A given program is written in one or the other of these two dialects.
> >>The program stands a chance to work on most any machine if it is
> >>compiled with the proper dialect. It is unlikely to work at all if
> >>compiled with the wrong dialect.
> >
> >It depends on the program, and whether or not chars in the user's
> >character set is sign extended (ie, in the USA, you likely won't notice
> >a difference between the two if chars just hold character values).
>
> You might notice if a -1 (EOF) becomes a 255 and you get an infinite
> loop in return (it did bite me). Of course, this is a bug in that
> outside the US a 255 character might become an EOF.
That'a a common bug with getchar() and similar function because people
put the result into a char before testing it, like:
char c;
while ((c=getchar())!=EOF) {
...
}
while the specification of getchar is that it returns an unsigned char
cast to an int or EOF, and therefore this code is incorrect independently
of whether char is signed or not:
- infinite loop when char is unsigned
- incomplete processing of a file because of early detection of EOF
when char is signed and you hit a 0xFF char.
I've been bitten by both (although the second one is less frequent now
since 0xff is invalid in UTF-8).
BTW, I'm of the very strong opinion that char should have been unsigned
by default because the name itself implies that it is used as a
enumeration of symbols, specialized to represent text. When you step
from one enum value to the following one (staying within the range of
valid values), you don't expect the new value to become lower than the
preceding one.
Things would be very different if it had been called "byte" or
"short short int" instead.
Gabriel
Re: Signed int overflow behaviour in the security context
Richard Kenner wrote: > I was addressing the claim that we allegedly have people writing security- > and/or safety-critical software who don't understand the semantics of that > language as they relate to safety and security (namely, what overflows do). > That's a serious problem. Of course, there's not a whole lot that we > as compiler writers can do with it (hence my smiley). You're misrepresenting the argument here. This is not just about newly written software, but also about software that already has been written. It's not just about security-critical software (whatever you think that is), but about the software you and I use every day. Think your desktop system. It's also not about programmers who don't understand about overflows, but about those who believe that overflows happen in a consistent manner. Also, of course there is something you can do as compiler writers, and that is to enable LIA-1 behaviour by default. "It's not my fault if people write buggy software" is a lame excuse for sloppy engineering on the part of gcc. It's not too much to ask to try a little harder to at least be consistent. Andreas
Re: Signed int overflow behaviour in the security context
On 1/25/07, Andreas Bogk <[EMAIL PROTECTED]> wrote: "It's not my fault if people write buggy software" is a lame excuse for sloppy engineering on the part of gcc. So basically you're saying gcc developers should compensate for other people's sloppy engineering? ;-) Gr. Steven
Re: Signed int overflow behaviour in the security context
> You're misrepresenting the argument here. This is not just about newly > written software, but also about software that already has been written. There are multiple arguments here. That comment of mine was addressing the claim that somebody (I think you) made that stated that it was too much to expect programmers writing security-critical code to understand these aspects of C. I agree with all the arguments about legacy code, but I'm much less tolerant of such arguments for NEW code.
Re: Signed int overflow behaviour in the security context
Steven Bosscher wrote: On 1/25/07, Andreas Bogk <[EMAIL PROTECTED]> wrote: "It's not my fault if people write buggy software" is a lame excuse for sloppy engineering on the part of gcc. So basically you're saying gcc developers should compensate for other people's sloppy engineering? ;-) Yes I would say! where possible this seems an excellent goal. Gr. Steven
Re: Signed int overflow behaviour in the security context
Steven Bosscher wrote: >> "It's not my fault if people write buggy software" is a lame excuse >> for sloppy engineering on the part of gcc. > So basically you're saying gcc developers should compensate for other > people's sloppy engineering? ;-) This might be a little exaggerated, but there's certainly some truth to it. Essentially, the vast majority of code in your Linux or BSD system was written by people who have no idea about the nasty things that can happen when their signed ints overflow. I guess you could call that "sloppy engineering", but unfortunately, this code and these programmers is all that Open Source got. The point is that gcc actually *can* compensate for this particular problem, whereas any other approach is infeasible for the sheer volume of code that needs to be touched. Yup, you're giving up a little performance for that. Yup, it's the other people who wrote broken code, and what gcc currently does is completely mandated by the ISO standard. Still, we're talking about dozens of undiscovered vulnerabilities, and just about any Linux or BSD box out there might be affected. Andreas
Re: Signed int overflow behaviour in the security context
Richard Kenner wrote: You're misrepresenting the argument here. This is not just about newly written software, but also about software that already has been written. There are multiple arguments here. That comment of mine was addressing the claim that somebody (I think you) made that stated that it was too much to expect programmers writing security-critical code to understand these aspects of C. Once again, the discussion is not about the narrow class of security-critical applications, but a more general one about all software where security is a consideration. I agree with all the arguments about legacy code, but I'm much less tolerant of such arguments for NEW code. new code is still written by legacy programmers. Compiler writers are in the business of creating compilers that are useable, not just ones that conform to the standard!
Re: Signed int overflow behaviour in the security context
Richard Kenner wrote: > I agree with all the arguments about legacy code, but I'm much less > tolerant of such arguments for NEW code. Thanks for clarification. I think legacy code is the big problem here anyways. Andreas
Re: [RFC] Our release cycles are getting longer
On Thu, Jan 25, 2007 at 11:18:34AM +0100, François-Xavier Coudert wrote: > [sorry for breaking the thread; stupid gmail doesn't want to add > custom References headers] > > >It may be that not too many people pick up 4.2.0. But, if 4.3 isn't > >looking very stable, there will be a point when people decide that 4.2.0 > >is looking very attractive. The worst outcome of trying to do a 4.2.0 > >release is that we'll fix some things that are also bugs in 4.3; most > >4.2 bugs are also in 4.3. > > >From the Fortran point of view, and however limited it might be, > skipping the 4.2.0 release would be very unfortunate. We've been > working hard on it, and especially in recent time, many bug fixes have > been deemed to risky to backport to the 4.1 branch. 4.3 is still a > long way down the road, and the 4.2 branch has interesting features > even from the non-Fortran point of view. > Gcc 4.2 has a serious FP performace issue: http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it will be addressed. H.J.
Re: [RFC] Our release cycles are getting longer
H. J. Lu wrote: Gcc 4.2 has a serious FP performace issue: http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it will be addressed. As always, the best way to ensure that it is addressed if it is important to you is to address it yourself, or pay someone to do so :-)
Re: [RFC] Our release cycles are getting longer
On Thu, Jan 25, 2007 at 09:57:45AM -0500, Robert Dewar wrote: > H. J. Lu wrote: > > >Gcc 4.2 has a serious FP performace issue: > > > >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html > > > >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it > >will be addressed. > > As always, the best way to ensure that it is addressed if it is > important to you is to address it yourself, or pay someone to do so :-) The fix is in mainline. The question is if it should be backported to 4.2. H.J.
Re: [RFC] Our release cycles are getting longer
On 1/25/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > >Gcc 4.2 has a serious FP performace issue: > > > >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html > > > >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it > >will be addressed. > > As always, the best way to ensure that it is addressed if it is > important to you is to address it yourself, or pay someone to do so :-) The fix is in mainline. The question is if it should be backported to 4.2. ISTR Dan already made it clear more than once that the answer to that question is a loud NO. Gr. Steven
Re: [RFC] Our release cycles are getting longer
On 1/25/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: On 1/25/07, H. J. Lu <[EMAIL PROTECTED]> wrote: > > >Gcc 4.2 has a serious FP performace issue: > > > > > >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html > > > > > >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it > > >will be addressed. > > > > As always, the best way to ensure that it is addressed if it is > > important to you is to address it yourself, or pay someone to do so :-) > > The fix is in mainline. The question is if it should be backported to > 4.2. ISTR Dan already made it clear more than once that the answer to that question is a loud NO. I thought it was more like "if you really want it I can do it". And I think without it 4.2 sucks. Richard.
RE: Signed int overflow behaviour in the security context
On 24 January 2007 12:51, Richard Kenner wrote: >> Your conclusion may well be correct. The question for this group is: >> what's the best that GCC can do to serve the community/society? > > Do all it can to discourage people from writing safety- or > security-critical code in a language they don't understand? ;-) You mean we should invoke the as-if rule in conjunction with the nasal demons tradition and /actually/ erase the user's hard-drive at compile time if they write a signed overflow? ;) cheers, DaveK -- Can't think of a witty .sigline today
Re: Signed int overflow behaviour in the security context
Dave Korn wrote: You mean we should invoke the as-if rule in conjunction with the nasal demons tradition and /actually/ erase the user's hard-drive at compile time if they write a signed overflow? ;) Well I already showed a case where assumptions of undefinedness could lead to such a result without any aid from the demons :-)
Re: [RFC] Our release cycles are getting longer
Mark Mitchell wrote on 01/25/07 00:09: First, I haven't had as much time to put in as RM lately as in past, so I haven't been nagging people as much. > Sure, but this is a trend that started with 3.1 and it's gotten progressively worse. Granted, we are now dealing with a much bigger project and perhaps the amount of engineering cycles has not kept up: Release Size (KLOC) 1.21 1988 58 1.38 1990 87 2.0 1992229 2.8.1 1998416 EGCS 1998603 2.95 1999715 3.0 2001 1,007 3.1 2002 1,336 4.0 2005 1,813 4.1 2006 2,109 4.2 2007 2,379 some people want/suggest more frequent releases. But, I've also had a number of people tell me that the 4.2 release cycle was too quick in its early stages, and that we didn't allow enough time to get features in -- even though doing so would likely have left us even more bugs to fix. > That's also true. The duration of our stage1 cycles has gone down quite a bit since 3.3. The data I have for the 3.x releases is a bit incomplete and we had a strange 3.2 release which I didn't include because we suddenly jumped from branching 3.1 to releasing 3.2 (that was the C++ ABI thing, IIRC). Anyway, here's the data I got from our release schedule. These are the durations of each stage since 3.1 Release Stage 1 Stage 2 Stage 3 Release 3.1 2002 0 65 69 212 3.3 2003 169 1 61 271 3.4 2004 262 103 93 289 4.0 2005 172 64 170 288 4.1 2006 59 74 133 309 4.2 2007 61 59 216 393 There is some correlation between the length of Stage1 to Stage3. It's as if longer Stage1s lead to shorter Stage3s. Perhaps we could consider lengthening the early stages, which by all accounts are the more "fun", and shorten the pain during stage 3. Long-lived branches are painful to maintain. If we allow them more time to get in mainline, it may help spread the stabilization work during stage1 (a lot more exposure). Another thing we could try again is going into mini-freeze cycles spanning 2-3 weeks. We've done that in the past when mainline was in a pathetic state and I think it was helpful. Some folks have suggested that we ought to try to line up FSF releases to help the Linux distributors. > I don't think that's in our best interest. We can't really help what distros do. The fact is, however, that when distros pick up a specific release, that release tends to be pretty solid (e.g. 4.1). I don't think that some of the ideas (like saying that you have to fix N bugs for every patch you contribute) are very practical. What we're seeing is telling us something about "the market" for GCC; there's more pressure for features, optimization, and ports than bug fixes. If there were enough people unhappy about bugs, there would be more people contributing bug fixes. Agreed. We are now in a featuritis phase. We still have many marketing bullet points that folks want filled in. I believe this will continue for at least a couple more releases. We are also being pulled from many directions at once, our user base is very diverse. Making the infrastructure more palatable for external folks to get involved in development and attract more engineering cycles is probably one of our best long term bets.
GCC-4.0.4 release status
Hi, There were over 250 PRs open against GCC-4.0.4. Almost all of them are "benign" in the sense that we can leave without fixing them in GCC-4.0.4 -- many are already fixed in more recent versions. I'm now giving attention only to those PRs marked as blocker or critical. I've identified three: tree-optimization/29605 * Wrong code generation when optimization is one. Andrew Pinski believes it is "Out of SSA" doing it. This touches middle-end, and will be left unfixed -- unless the fix is really really trivial. tree-optimization/28778 * not to be fixed in GCC-4.0.x middle-end/28683 * has a "simple" patch applied to GCC-4.2.x and GCC-4.1.x. I'm considering applying to GCC-4.0.4. So, middle-end/28683 is the only PR that might get fixed. I'll appreciate middle-end maintainers have a second look at the patch and say how confident they fill about it. Tomorrow, I'll issue a pre-release for testing. A final release should be expected for January 31st, 2007. Thanks, -- Gaby
Re: GCC-4.0.4 release status
On 25 Jan 2007 10:29:27 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: Hi, There were over 250 PRs open against GCC-4.0.4. Almost all of them are "benign" in the sense that we can leave without fixing them in GCC-4.0.4 -- many are already fixed in more recent versions. I'm now giving attention only to those PRs marked as blocker or critical. I've identified three: tree-optimization/29605 * Wrong code generation when optimization is one. Andrew Pinski believes it is "Out of SSA" doing it. This touches middle-end, and will be left unfixed -- unless the fix is really really trivial. tree-optimization/28778 * not to be fixed in GCC-4.0.x middle-end/28683 * has a "simple" patch applied to GCC-4.2.x and GCC-4.1.x. I'm considering applying to GCC-4.0.4. You might want to consider middle-end/28651 given the recent integer overflow discussions. I can do the backport work if you like. Richard.
Re: GCC-4.0.4 release status
Hi, > There were over 250 PRs open against GCC-4.0.4. Almost all of > them are "benign" in the sense that we can leave without fixing them > in GCC-4.0.4 -- many are already fixed in more recent versions. > I'm now giving attention only to those PRs marked as blocker or > critical. I've identified three: Well, there's another serious (wrong-code) bug which should be fixed IMHO: PR c++/29106 is a C++ front-end issue. It has a one-line fix (plus comment) on the 4.1 branch. Well, actually one should also backport the fix for PR c++/28284 then, which is a two-liner. Unfortunately, I didn't find the time to test the patch myself. Regards, Volker
Re: GCC-4.0.4 release status
On Thu, 25 Jan 2007, Richard Guenther wrote: | You might want to consider middle-end/28651 given the recent integer overflow | discussions. Good suggestion! | I can do the backport work if you like. If you could work out a backport by tomorrow morning (CST), that would would great. Thanks! -- Gaby
Re: RFC: Wextra digest (fixing PR7651)
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: | A summary of what has been proposed so far to clean up Wextra follows. | Please, your feedback is appreciated. And reviewing patches even more | ;-) Thanks for this digest; I'd give your feedback tonight. -- Gaby
Re: RFC: Wextra digest (fixing PR7651)
On 25 Jan 2007 11:17:41 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: | A summary of what has been proposed so far to clean up Wextra follows. | Please, your feedback is appreciated. And reviewing patches even more | ;-) Thanks for this digest; I'd give your feedback tonight. Thanks. I understand that you are busy with the 4.0.4 release, so don't need to hurry up! I am not having much free time lately either. Cheers, Manuel.
Re: GCC-4.0.4 release status
Volker Reichelt <[EMAIL PROTECTED]> writes: | Hi, | | > There were over 250 PRs open against GCC-4.0.4. Almost all of | > them are "benign" in the sense that we can leave without fixing them | > in GCC-4.0.4 -- many are already fixed in more recent versions. | > I'm now giving attention only to those PRs marked as blocker or | > critical. I've identified three: | | Well, there's another serious (wrong-code) bug which should be fixed IMHO: | | PR c++/29106 is a C++ front-end issue. | It has a one-line fix (plus comment) on the 4.1 branch. | Well, actually one should also backport the fix for PR c++/28284 then, | which is a two-liner. I was primarily looking at the PRs that marked in the bugzilla database blocker or critical. As there were over 256 PRs open, and the idea is to get GCC-4.0.4 out of the door as soon as possible, I'm not trying to fix everything; just those that are critical or blockers. This is based on the fact that most distros have moved to GCC-4.1.x or higher. GCC-4.0.x has been since GCC-4.0.0 to contain major shortcomings. -- Gaby
Re: RFC: Wextra digest (fixing PR7651)
On Thu, 25 Jan 2007, Manuel López-Ibáñez wrote: | Thanks. I understand that you are busy with the 4.0.4 release, so | don't need to hurry up! I was busy with daytime job. -- Gaby
initialization and enums in new version of gcc
I whant to know if the enum definition was changed in the last versions of
gcc because in the ansi C you can not define:
enum COLOR{RED,GREEN,};
the last comma only is correct if you are defining an initialization of a
variable. But it is allowed in gcc 4.1.1
Laura.-
Re: GCC4 makes off by ones more exploitable again, misuse of padding?
On Thursday 25 January 2007 01:43, In Cognito wrote: > > > 0x080483a7 :sub$0x208,%esp > > > 0x080483ad :mov0x8(%ebp),%eax > > > 0x080483b0 : mov%eax,0x4(%esp) > > > 0x080483b4 : lea0xfe00(%ebp),%eax > > > 0x080483ba : mov%eax,(%esp) > > > 0x080483bd : call 0x80482e8 <[EMAIL PROTECTED]> > > > 0x080483c2 : leave > > > 0x080483c3 : ret > > > > > > 0x208 = 520 bytes; alright padding can be useful > > > 0xfe00(%ebp) = -512 + ebp. > > > > What padding? It's a place for strcpy parameters... > > char buf[512] > > sub$0x208,%esp > > 0x208 = 520 bytes allocated on the stack. there are 8 extra bytes > between %esp and buf[0]. Exactly. Two 32-bit stack slots. And look for what these two stack slots are used: > > > 0x080483ad :mov0x8(%ebp),%eax > > > 0x080483b0 : mov%eax,0x4(%esp) [esp+4] = b > > > 0x080483b4 : lea0xfe00(%ebp),%eax > > > 0x080483ba : mov%eax,(%esp)[esp] = &buf > > > 0x080483bd : call 0x80482e8 <[EMAIL PROTECTED]> call strcpy This is it. strcpy will see them on stack as parameters. It isn't padding. -- vda
Re: initialization and enums in new version of gcc
"Laura Tardivo" <[EMAIL PROTECTED]> writes:
> I whant to know if the enum definition was changed in the last versions of
> gcc because in the ansi C you can not define:
>
> enum COLOR{RED,GREEN,};
>
> the last comma only is correct if you are defining an initialization of a
> variable. But it is allowed in gcc 4.1.1
This question is not appropriate for the gcc@gcc.gnu.org mailing list,
which is a mailing list for gcc developers. It would be appropriate
for [EMAIL PROTECTED]
gcc accepts the trailing comma by default. If you use the -pedantic
option you will get a warning. See the description of -pedantic in
the gcc manual.
Ian
Re: 2007 GCC Developers Summit
On Wed, Jan 24, 2007 at 04:10:18PM -0500, Andrew J. Hutton wrote: > We would like to invite everyone to read over the Call for Papers for > the 2007 GCC Developers' Summit located at > http://www.gccsummit.org/2007/cfp.php and to consider submitting a > proposal for this year. > > This year we're going to be from July 18th to 20th for a change and hope > that you're all able to make it this year. > > Please forward the CFP URL to anyone you feel would be interested in > attending. Also think about what kinds of presentations you'd like to hear and encourage the appropriate people to submit proposals about those topics. Janis
RE: [OT] char should be signed by default
> -Original Message-
> From: Gabriel Paubert [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 25, 2007 5:43 AM
> To: Paolo Bonzini
> Cc: Meissner, Michael; [EMAIL PROTECTED]; gcc@gcc.gnu.org
> Subject: Re: [OT] char should be signed by default
>
> On Thu, Jan 25, 2007 at 10:29:29AM +0100, Paolo Bonzini wrote:
> >
> > >>A given program is written in one or the other of these two
dialects.
> > >>The program stands a chance to work on most any machine if it is
> > >>compiled with the proper dialect. It is unlikely to work at all if
> > >>compiled with the wrong dialect.
> > >
> > >It depends on the program, and whether or not chars in the user's
> > >character set is sign extended (ie, in the USA, you likely won't
notice
> > >a difference between the two if chars just hold character values).
> >
> > You might notice if a -1 (EOF) becomes a 255 and you get an infinite
> > loop in return (it did bite me). Of course, this is a bug in that
> > outside the US a 255 character might become an EOF.
>
> That'a a common bug with getchar() and similar function because people
> put the result into a char before testing it, like:
>
> char c;
> while ((c=getchar())!=EOF) {
> ...
> }
>
> while the specification of getchar is that it returns an unsigned char
> cast to an int or EOF, and therefore this code is incorrect
independently
> of whether char is signed or not:
> - infinite loop when char is unsigned
> - incomplete processing of a file because of early detection of EOF
> when char is signed and you hit a 0xFF char.
Yep. This was discussed in the ANSI X3J11 committee in the 80's, and it
is a problem (and the program is broken because getchar does return the
one out of band return value). Another logical problem that occurs is
if you are on a system where char and int are the same size, that there
is no out of band
Value that can be returned, and in theory the only correct way is to use
feof and ferror, which few people do.
> I've been bitten by both (although the second one is less frequent now
> since 0xff is invalid in UTF-8).
>
> BTW, I'm of the very strong opinion that char should have been
unsigned
> by default because the name itself implies that it is used as a
> enumeration of symbols, specialized to represent text. When you step
> from one enum value to the following one (staying within the range of
> valid values), you don't expect the new value to become lower than the
> preceding one.
And then there is EBCDIC, where there are 10 characters between 'I' and
'J' if memory serves. Plus the usual problem in ASCII that the national
characters that are alphabetic aren't grouped with the A-Z, a-z
characters.
> Things would be very different if it had been called "byte" or
> "short short int" instead.
>
> Gabriel
>
--
Michael Meissner
AMD, MS 83-29
90 Central Street
Boxborough, MA 01719
Re: RE: char should be signed by default
> - Original Message - > From: "Meissner, Michael" <[EMAIL PROTECTED]> > Date: Wednesday, January 24, 2007 12:49 pm > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of > > [EMAIL PROTECTED] > > Sent: Wednesday, January 24, 2007 12:19 AM > > To: gcc@gcc.gnu.org > > Subject: char should be signed by default > > > > The GNU C compiler supports both dialects; you can specify the signed > > dialect with -fsigned-char and the unsigned dialect with > > -funsigned-char. However, this leaves open the question of which > > dialect to use by default. > > You use the ABI, which specifies whether chars and plain bitfields > signextend or not. GCC ignores the ABI w.r.t. bit-fields: http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Non_002dbugs.html s/bit-fields/char/ ;-)
Re: GCC4 makes off by ones more exploitable again, misuse of padding?
Let me try to clarify. GCC is allocated more than 512 bytes, 0x080483a7 :sub$0x208,%esp 0x208= 520 in this case. Where are those extra 8 bytes? They're in between what gcc is considering the start of buf, &buf[0] and %esp (the top of the stack). I'm considering those extra 8 bytes to be the "padding". buf[0] is at 0xfe00(%ebp) [ -512(%ebp) ]. I would prefer that gcc started buf at 0xfdf8(%ebp), leaving those 8 bytes in between buf[511] and the saved frame pointer *(%ebp) instead. If the padding is there anyway, I would prefer it was used to improve security, as gcc 3 used to. On 1/25/07, Denis Vlasenko <[EMAIL PROTECTED]> wrote: On Thursday 25 January 2007 01:43, In Cognito wrote: > > > 0x080483a7 :sub$0x208,%esp > > > 0x080483ad :mov0x8(%ebp),%eax > > > 0x080483b0 : mov%eax,0x4(%esp) > > > 0x080483b4 : lea0xfe00(%ebp),%eax > > > 0x080483ba : mov%eax,(%esp) > > > 0x080483bd : call 0x80482e8 <[EMAIL PROTECTED]> > > > 0x080483c2 : leave > > > 0x080483c3 : ret > > > > > > 0x208 = 520 bytes; alright padding can be useful > > > 0xfe00(%ebp) = -512 + ebp. > > > > What padding? It's a place for strcpy parameters... > > char buf[512] > > sub$0x208,%esp > > 0x208 = 520 bytes allocated on the stack. there are 8 extra bytes > between %esp and buf[0]. Exactly. Two 32-bit stack slots. And look for what these two stack slots are used: > > > 0x080483ad :mov0x8(%ebp),%eax > > > 0x080483b0 : mov%eax,0x4(%esp) [esp+4] = b > > > 0x080483b4 : lea0xfe00(%ebp),%eax > > > 0x080483ba : mov%eax,(%esp)[esp] = &buf > > > 0x080483bd : call 0x80482e8 <[EMAIL PROTECTED]> call strcpy This is it. strcpy will see them on stack as parameters. It isn't padding. -- vda
Re: GCC-4.0.4 release status
On 1/25/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: On Thu, 25 Jan 2007, Richard Guenther wrote: | You might want to consider middle-end/28651 given the recent integer overflow | discussions. Good suggestion! | I can do the backport work if you like. If you could work out a backport by tomorrow morning (CST), that would would great. Done. Bootstrapped and tested on x86_64-unknown-linux-gnu. Richard.
Re: GCC-4.0.4 release status
On Thu, 25 Jan 2007, Richard Guenther wrote: | On 1/25/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: | > On Thu, 25 Jan 2007, Richard Guenther wrote: | > | > | You might want to consider middle-end/28651 given the recent integer overflow | > | discussions. | > | > Good suggestion! | > | > | I can do the backport work if you like. | > | > If you could work out a backport by tomorrow morning (CST), that would | > would great. | | Done. Bootstrapped and tested on x86_64-unknown-linux-gnu. Thanks! -- Gaby
Re: GCC4 makes off by ones more exploitable again, misuse of padding?
On Thu, Jan 25, 2007 at 02:02:47PM -0500, In Cognito wrote: > Let me try to clarify. > GCC is allocated more than 512 bytes, > >0x080483a7 :sub$0x208,%esp > 0x208= 520 in this case. > > Where are those extra 8 bytes? They're in between what > gcc is considering the start of buf, &buf[0] and %esp (the top of the > stack). > I'm considering those extra 8 bytes to be the "padding". A joke attributed to Abraham Lincoln: "How many legs does a horse have if we call a tail a leg?" "Five." "No, four. Calling a tail a leg doesn't make it a leg." You just ignored what Denis wrote and said the same thing again. The extra eight bytes are *not padding*. They are parameters to strcpy. It just so happens that in this particular case, overwriting those parameters will be harmless *if* copies of those parameters are in registers and only the registers are used. But you are falsely generalizing from one example; in other cases (particularly on x86 with few registers) those parameters will be read back in from memory again. You falsely believe that gcc 2.x introduced padding around arrays. It did not.
Re: GCC-4.0.4 release status
On Thu, Jan 25, 2007 at 05:42:31PM +0100, Volker Reichelt wrote: > Hi, > > > There were over 250 PRs open against GCC-4.0.4. Almost all of > > them are "benign" in the sense that we can leave without fixing them > > in GCC-4.0.4 -- many are already fixed in more recent versions. > > I'm now giving attention only to those PRs marked as blocker or > > critical. I've identified three: > > Well, there's another serious (wrong-code) bug which should be fixed IMHO: > > PR c++/29106 is a C++ front-end issue. > It has a one-line fix (plus comment) on the 4.1 branch. > Well, actually one should also backport the fix for PR c++/28284 then, > which is a two-liner. > > Unfortunately, I didn't find the time to test the patch myself. The goal of 4.0.4 is to get out the code that is already in the 4.0 branch and then shut it down, so we can then close about 150 "only in 4.0.x" bugs and be done with it. To me, the only strong criterion is that 4.0.4 should be strictly better than 4.0.3; AFAIK none of the three bugs Gaby mentioned work in 4.0.3. It might be worth fixing a couple of wrong-code bugs that are already fixed in 4.1 and have very trivial fixes. I don't think it's wise, though, to backport fixes from the 4.1 branch that are broken in 4.1.1 unless there's a really strong justification. We don't want to create incentives to move backwards.
Re: GCC-4.0.4 release status
On Thu, 25 Jan 2007, Joe Buck wrote: | It might be worth fixing a couple of wrong-code bugs that are already | fixed in 4.1 and have very trivial fixes. I don't think it's wise, | though, to backport fixes from the 4.1 branch that are broken in 4.1.1 | unless there's a really strong justification. We don't want to create | incentives to move backwards. I strongly agree. -- Gaby
Re: 2007 GCC Developers Summit
On Wed, Jan 24, 2007 at 04:10:18PM -0500, Andrew J. Hutton wrote: > > We would like to invite everyone to read over the Call for Papers for > > the 2007 GCC Developers' Summit located at > > http://www.gccsummit.org/2007/cfp.php and to consider submitting a > > proposal for this year. On Thu, Jan 25, 2007 at 10:36:04AM -0800, Janis Johnson wrote: > Also think about what kinds of presentations you'd like to hear and > encourage the appropriate people to submit proposals about those topics. It would be good to bring in the user perspective, for example, a discussion among people who are responsible for building complete GNU/Linux or BSD distributions with GCC. What problems are they experiencing, how have things changed over time, how does the state of GCC look from their perspective, is there anything GCC could do that would make their jobs easier (yeah yeah, run 10x faster and make smaller, better code. How about anything that is achievable)? It could be an invited session.
Re: subreg_get_info vs mode restrictions in registers?
On Wed, Jan 24, 2007 at 08:39:47PM -0500, DJ Delorie wrote: > > Here's an example of bad assumptions. The current code calculates the > subreg location BEFORE checking to see if such a subreg is legal. > This patch moved the legality check before the location calculations. See also http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00241.html>. You probably need to be prepared, whatever that means, for HARD_REGNO_NREGS() to be called with parameters for which HARD_REGNO_MODE_OK() returns 0. As you've found out, subreg_get_info() might do that. -- Rask Ingemann Lambertsen
RE: RE: char should be signed by default
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 25, 2007 1:54 PM > To: Meissner, Michael > Cc: gcc@gcc.gnu.org > Subject: Re: RE: char should be signed by default > > > - Original Message - > > From: "Meissner, Michael" <[EMAIL PROTECTED]> > > Date: Wednesday, January 24, 2007 12:49 pm > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > > Of > > > [EMAIL PROTECTED] > > > Sent: Wednesday, January 24, 2007 12:19 AM > > > To: gcc@gcc.gnu.org > > > Subject: char should be signed by default > > > > > > The GNU C compiler supports both dialects; you can specify the signed > > > dialect with -fsigned-char and the unsigned dialect with > > > -funsigned-char. However, this leaves open the question of which > > > dialect to use by default. > > > > You use the ABI, which specifies whether chars and plain bitfields > > signextend or not. > > GCC ignores the ABI w.r.t. bit-fields: > > http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Non_002dbugs.html > > s/bit-fields/char/ ;-) Yes, and in 1989, I fought that issue with RMS and lost then. It still doesn't change my opinion that GCC should adhere to the local ABI. -- Michael Meissner AMD, MS 83-29 90 Central Street Boxborough, MA 01719
Re: GCC-4.0.4 release status
Hi, > | Well, there's another serious (wrong-code) bug which should be fixed IMHO: > | > | PR c++/29106 is a C++ front-end issue. > | It has a one-line fix (plus comment) on the 4.1 branch. > | Well, actually one should also backport the fix for PR c++/28284 then, > | which is a two-liner. > I was primarily looking at the PRs that marked in the bugzilla > database blocker or critical. As there were over 256 PRs open, and > the idea is to get GCC-4.0.4 out of the door as soon as possible, I'm > not trying to fix everything; just those that are critical or > blockers. This is based on the fact that most distros have moved to > GCC-4.1.x or higher. GCC-4.0.x has been since GCC-4.0.0 to contain > major shortcomings. Well, the severity status of the bugs is not very well maintained. Mark e.g. only sets the prioriy field (P1 - P5) of the bugs. And PR 29106 bug is one of the 37 P1 bugs. And one from three wrong-code P1 bugs. So this is not like every simple error-recovery problem. In addition this is a regression from GCC 4.0.2, i.e. a regression on the 4.0 branch. Which makes this bug even worse, IMHO. (This infromation seems to be missing in bugzilla, though.) Considering how much dispute there is on the mailing list about how to handle undefined behaviour correctly ;-), it bothers me more that we ignore one-lines fixes for wrong-code bugs. Regards, Volker
Re: gcc compile time support for assumptions
Ian Lance Taylor wrote on 01/18/07 10:51: Well, internally, we do have ASSERT_EXPR. It would probably take a little work to permit the frontends to generate it, but the optimizers should understand it. By default, they do not. When I initially implemented VRP, I was adding ASSERT_EXPRs right after gimplification. The rationale was to have the ASSERT_EXPRs rewritten into SSA form by the initial SSA pass. This was convenient, but it destroyed the quality of generated code. Suddenly, little or no copies, constants were being propagated, jump threading wasn't working, PRE wasn't doing its job, etc. The problem was that all these ASSERT_EXPRs were not being grokked by the optimizers, every optimizer would see the assertion, think the worst and block transformations. It also meant quite a bit of bulk added to the IL which increased compilation times. So, if we decide to add ASSERT_EXPRs early in the pipeline, we have to mind these issues. In the end, I went for adding assertions inside VRP and fixing up the SSA form incrementally. Perhaps we can do something similar for other passes that may want to deal with assertions. Now, if these are assertions inserted by the user, that's another problem. The IL wouldn't bulk up so much, but we would still need to handle them everywhere. Assertions shouldn't block scalar cleanups.
Re: GCC-4.0.4 release status
On 1/25/07, Volker Reichelt <[EMAIL PROTECTED]> wrote: Hi, > | Well, there's another serious (wrong-code) bug which should be fixed IMHO: > | > | PR c++/29106 is a C++ front-end issue. > | It has a one-line fix (plus comment) on the 4.1 branch. > | Well, actually one should also backport the fix for PR c++/28284 then, > | which is a two-liner. > I was primarily looking at the PRs that marked in the bugzilla > database blocker or critical. As there were over 256 PRs open, and > the idea is to get GCC-4.0.4 out of the door as soon as possible, I'm > not trying to fix everything; just those that are critical or > blockers. This is based on the fact that most distros have moved to > GCC-4.1.x or higher. GCC-4.0.x has been since GCC-4.0.0 to contain > major shortcomings. Well, the severity status of the bugs is not very well maintained. Mark e.g. only sets the prioriy field (P1 - P5) of the bugs. And PR 29106 bug is one of the 37 P1 bugs. And one from three wrong-code P1 bugs. So this is not like every simple error-recovery problem. In addition this is a regression from GCC 4.0.2, i.e. a regression on the 4.0 branch. Which makes this bug even worse, IMHO. (This infromation seems to be missing in bugzilla, though.) Considering how much dispute there is on the mailing list about how to handle undefined behaviour correctly ;-), it bothers me more that we ignore one-lines fixes for wrong-code bugs. I think regressions on the branch are worth a fix. Though I agree that the primary goal should be to get rid of the 4.0 branch ;) Richard.
Re: Signed int overflow behaviour in the security context
Robert Dewar wrote: >> So basically you're saying gcc developers should compensate for other >> people's sloppy engineering? ;-) > > Yes I would say! where possible this seems an excellent goal. I agree: when it's possible to support non-standard legacy semantics that do not conflict with the standard, without substantial negative impact, then that's a good thing to do. In this specific case, we know there is a significant performance impact, and we know that performance is very important to both the existing and potential GCC user base, so I think that making the compiler more aggressive at -O2 is sensible. And, Ian is working on -fno-strict-overflow, so that users have a choice, which is also very sensible. Perhaps the distribution vendors will then add value by selectively compiling packages that need it with -fno-strict-overflow so that security-critical packages are that much less likely to do bad things, while making the rest of the system go faster by not using the option. I think we've selected a very reasonable path here. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
reading binarys
I'm working on a project where every so often one of our games comes back and we pull the ram off the game for saving, and sometimes for anaylisis. Currently the only varibles in ram that we can physically look at are the static members. The information that we would love to get to is the heap memory and be able to know what dynamically allocated structure that heap memory belongs to. I have the source code, I have the binarys, I have the ram dumps, I have the boards. Our games have the ability to recover back to the original state that they were in before a power hit, so even though the memory is dynamically allocated, our code is the only running code on the machine and since it runs the code in the same order every time, the pointers get put into the same memory locations every time. What I need to know, is there some way to read the binary with some program to figure out which order everything in memory is being allocated, so that I can write a program to read the memory dump and figure out which memory locations belong to which pointer varibles. Our code is written in C with litteraly tons of pointers. It runs on the i960 processor (yeah I know...soo old...but it works and it costs a lot of money to change once its been approved). Any ideas would be appricated to be able to read the binary to figure out the order in which varibles get loaded onto the heap.
Re: reading binarys
On Jan 25, 2007, at 2:11 PM, Jason Erickson wrote: I'm working on a project where every so often one of our games comes back and we pull the ram off the game for saving, and sometimes for anaylisis. Currently the only varibles in ram that we can physically look at are the static members. The information that we would love to get to is the heap memory and be able to know what dynamically allocated structure that heap memory belongs to. Heap objects can be found by looking at stack and global variables. What I need to know, is there some way to read the binary with some program to figure out which order everything in memory is being allocated, so that I can write a program to read the memory dump and figure out which memory locations belong to which pointer varibles. Our code is written in C with litteraly tons of pointers. It runs on the i960 processor (yeah I know...soo old...but it works and it costs a lot of money to change once its been approved). Any ideas would be appricated to be able to read the binary to figure out the order in which varibles get loaded onto the heap. First, wrong list. gcc-help is closer, but that is for compiler help. Your question really has little to do with the compiler, but rather, debugging. You could create a gdb remote stub for your game and then just fire up gdb with the `core file'. Assumes that you've enhanced gdb to read your core files. You can save off the -g built game and point the debugger at that code. You then debug any data structures you want, using gdb. If you just want a memory map, see the ld documentation. If you're question is how do I write a debugger, please, don't do that, just reuse gdb. It supports remote debugging and i960s just fine.
Re: reading binarys
I''l give that a shot. Thanks On 1/25/07, Mike Stump <[EMAIL PROTECTED]> wrote: On Jan 25, 2007, at 2:11 PM, Jason Erickson wrote: > I'm working on a project where every so often one of our games comes > back and we pull the ram off the game for saving, and sometimes for > anaylisis. Currently the only varibles in ram that we can physically > look at are the static members. The information that we would love to > get to is the heap memory and be able to know what dynamically > allocated structure that heap memory belongs to. Heap objects can be found by looking at stack and global variables. > What I need to know, is there some way to read the binary with some > program to figure out which order everything in memory is being > allocated, so that I can write a program to read the memory dump and > figure out which memory locations belong to which pointer varibles. > Our code is written in C with litteraly tons of pointers. It runs on > the i960 processor (yeah I know...soo old...but it works and it costs > a lot of money to change once its been approved). > > Any ideas would be appricated to be able to read the binary to figure > out the order in which varibles get loaded onto the heap. First, wrong list. gcc-help is closer, but that is for compiler help. Your question really has little to do with the compiler, but rather, debugging. You could create a gdb remote stub for your game and then just fire up gdb with the `core file'. Assumes that you've enhanced gdb to read your core files. You can save off the -g built game and point the debugger at that code. You then debug any data structures you want, using gdb. If you just want a memory map, see the ld documentation. If you're question is how do I write a debugger, please, don't do that, just reuse gdb. It supports remote debugging and i960s just fine. -- Jennys Website http://www.dontbflat.com
Possible build problems with the "current" gcc
Howdy, I've been seeing this error for the past couple of days. Am I doing something wrong here? Regards and thanks, George... (cd .libs && rm -f libclasspath.la && ln -s ../libclasspath.la libclasspath.la) make[8]: Leaving directory `/tools/tools/gcc/obj-i686-pc-linux-gnu/x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni/classpath' Making all in midi-dssi make[8]: Entering directory `/tools/tools/gcc/obj-i686-pc-linux-gnu/x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni/midi-dssi' if /bin/bash ../../../libtool --mode=compile /tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc -B/tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/lib/ -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/include -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi -I../../../include -I../../../../../../../../gcc/libjava/classpath/include -I../../../../../../../../gcc/libjava/classpath/native/jni/classpath -I../../../../../../../../gcc/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -O2 -g -O2 -m32 -MT gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.lo -MD -MP -MF ".deps/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.Tpo" -c -o gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.lo ../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.c; \ then mv -f ".deps/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.Tpo" ".deps/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.Plo"; else rm -f ".deps/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.Tpo"; exit 1; fi if /bin/bash ../../../libtool --mode=compile /tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc -B/tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/lib/ -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/include -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi -I../../../include -I../../../../../../../../gcc/libjava/classpath/include -I../../../../../../../../gcc/libjava/classpath/native/jni/classpath -I../../../../../../../../gcc/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -O2 -g -O2 -m32 -MT gnu_javax_sound_midi_dssi_DSSISynthesizer.lo -MD -MP -MF ".deps/gnu_javax_sound_midi_dssi_DSSISynthesizer.Tpo" -c -o gnu_javax_sound_midi_dssi_DSSISynthesizer.lo ../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi/gnu_javax_sound_midi_dssi_DSSISynthesizer.c; \ then mv -f ".deps/gnu_javax_sound_midi_dssi_DSSISynthesizer.Tpo" ".deps/gnu_javax_sound_midi_dssi_DSSISynthesizer.Plo"; else rm -f ".deps/gnu_javax_sound_midi_dssi_DSSISynthesizer.Tpo"; exit 1; fi make[8]: Warning: File `../../../native/jni/classpath/jcl.lo' has modification time 3.6e+02 s in the future mkdir .libs /tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc -B/tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/lib/ -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/include -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi -I../../../include -I../../../../../../../../gcc/libjava/classpath/include -I../../../../../../../../gcc/libjava/classpath/native/jni/classpath -I../../../../../../../../gcc/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -O2 -g -O2 -m32 -MT gnu_javax_sound_midi_dssi_DSSISynthesizer.lo -MD -MP -MF .deps/gnu_javax_sound_midi_dssi_DSSISynthesizer.Tpo -c ../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi/gnu_javax_sound_midi_dssi_DSSISynthesizer.c -fPIC -DPIC -o .libs/gnu_javax_sound_midi_dssi_DSSISynthesizer.o /tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc -B/tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/lib/ -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/include -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi -I../../../include -I../../../../../../../../gcc/libjava/classpath/include -I../../../../../../../../gcc/libjava/classpath/native/jni/classpath -I../../../../../../../../gcc/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -O2 -g -O2 -m32 -MT gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.lo -MD -MP -MF .deps/gnu_j
Re: Possible build problems with the "current" gcc
On Thu, Jan 25, 2007 at 04:21:28PM -0800, George R Goffe wrote: > Howdy, > > I've been seeing this error for the past couple of days. Am I doing something > wrong > here? The following message is worrying: > make[8]: Warning: File `../../../native/jni/classpath/jcl.lo' has > modification time > 3.6e+02 s in the future You get messages like that is if your NFS client and server disagree about the time. Since make uses file times to figure out what to build, it is likely that builds will malfunction. Fix your clock, or run a time daemon (e.g. ntpd) to keep things in sync.
Possible build problems with the "current" gcc
Howdy, I got an email from Joe Buck who suggested that I fix a clock skew problem between 2 of my systems. I did this but this did not change the "other" problem with this build effort. A diff of the 2 sets of error messages showed that the clock problem did in fact disappear. Any ideas as to how to proceed with this one would be greatly appreciated. Regards and thanks, George... make[8]: Entering directory `/tools/tools/gcc/obj-i686-pc-linux-gnu/x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni/midi-dssi' if /bin/bash ../../../libtool --mode=compile /tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc -B/tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/lib/ -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/include -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi -I../../../include -I../../../../../../../../gcc/libjava/classpath/include -I../../../../../../../../gcc/libjava/classpath/native/jni/classpath -I../../../../../../../../gcc/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -O2 -g -O2 -m32 -MT gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.lo -MD -MP -MF ".deps/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.Tpo" -c -o gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.lo ../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.c; \ then mv -f ".deps/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.Tpo" ".deps/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.Plo"; else rm -f ".deps/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.Tpo"; exit 1; fi if /bin/bash ../../../libtool --mode=compile /tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc -B/tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/lib/ -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/include -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi -I../../../include -I../../../../../../../../gcc/libjava/classpath/include -I../../../../../../../../gcc/libjava/classpath/native/jni/classpath -I../../../../../../../../gcc/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -O2 -g -O2 -m32 -MT gnu_javax_sound_midi_dssi_DSSISynthesizer.lo -MD -MP -MF ".deps/gnu_javax_sound_midi_dssi_DSSISynthesizer.Tpo" -c -o gnu_javax_sound_midi_dssi_DSSISynthesizer.lo ../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi/gnu_javax_sound_midi_dssi_DSSISynthesizer.c; \ then mv -f ".deps/gnu_javax_sound_midi_dssi_DSSISynthesizer.Tpo" ".deps/gnu_javax_sound_midi_dssi_DSSISynthesizer.Plo"; else rm -f ".deps/gnu_javax_sound_midi_dssi_DSSISynthesizer.Tpo"; exit 1; fi mkdir .libs /tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc -B/tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/lib/ -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/include -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi -I../../../include -I../../../../../../../../gcc/libjava/classpath/include -I../../../../../../../../gcc/libjava/classpath/native/jni/classpath -I../../../../../../../../gcc/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -O2 -g -O2 -m32 -MT gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.lo -MD -MP -MF .deps/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.Tpo -c ../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.c -fPIC -DPIC -o .libs/gnu_javax_sound_midi_dssi_DSSIMidiDeviceProvider.o /tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/xgcc -B/tools/tools/gcc/obj-i686-pc-linux-gnu/./gcc/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -B/usr/lsd/Linux/x86_64-unknown-linux-gnu/lib/ -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/include -isystem /usr/lsd/Linux/x86_64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../../../../../gcc/libjava/classpath/native/jni/midi-dssi -I../../../include -I../../../../../../../../gcc/libjava/classpath/include -I../../../../../../../../gcc/libjava/classpath/native/jni/classpath -I../../../../../../../../gcc/libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -O2 -g -O2 -m32 -MT gnu_javax_sound_midi_dssi_DSSISynthesizer.lo -MD -MP -MF .deps/gnu_javax_sound_midi_dssi_DSSISynthesizer.Tpo -c ../../../../../../../../g
Re: Possible build problems with the "current" gcc
On Thu, Jan 25, 2007 at 07:22:46PM -0800, George R Goffe wrote: > Howdy, > > I got an email from Joe Buck who suggested that I fix a clock skew problem > between 2 > of my systems. I did this but this did not change the "other" problem with > this > build effort. A diff of the 2 sets of error messages showed that the clock > problem > did in fact disappear. > > Any ideas as to how to proceed with this one would be greatly appreciated. > Do you have symlinks in your gcc source tree? H.J.
The Linux binutils 2.17.50.0.11 is released
This is the beta release of binutils 2.17.50.0.11 for Linux, which is
based on binutils 2007 0125 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.17.50.0.11 to [EMAIL PROTECTED]
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.17.50.0.10:
1. Update from binutils 2007 0125.
2. Support environment variables, LD_SYMBOLIC for -Bsymbolic and
LD_SYMBOLIC_FUNCTIONS for -Bsymbolic-functions.
3. Build binutils rpm with LD_SYMBOLIC_FUNCTIONS=1 and reduce PLT
relocations in libfd.so by 84%.
4. Enable sharable sections only for ia32, x86-64 and ia64.
5. Properly handle PT_GNU_RELRO segment for objcopy.
Changes from binutils 2.17.50.0.9:
1. Update from binutils 2007 0122.
2. Implement sharable section proposal for ia32, x86-64 and ia64:
http://groups-beta.google.com/group/generic-abi
3. Implement linker enhancement, -Bsymbolic-functions,
--dynamic-list-cpp-new and --dynamic-list-data. PR 3831.
4. Implement new linker switch, --default-script=FILE/-dT FILE.
5. Check EI_OSABI when reading ELF files. PR 3826.
6. Fix x86 assembler error message. PR 3830.
7. Fix a bug in ld testsuite. PR 1283.
8. Don't include archive64.o for 32bit target. PR 3631.
9. Support -z max-page-size and -z common-page-size in user provided
linker script.
10. Fix 32bit library support for GNU/kFreeBSD/x86-64. PR 3843.
11. Fix some bugs in Score assembler. PR 3871.
12. Fix various bugs in ARM assembler. PR 3707 and more.
13. Add Fido support.
Changes from binutils 2.17.50.0.8:
1. Update from binutils 2007 0103.
2. Fix --wrap linker bug.
3. Improve handling ELF binaries generated by foreign ELF linkers.
4. Various ELF M68K bug fixes.
5. Score bug fixes.
6. Don't read past end of archive elements. PR 3704.
7. Improve .eh_frame_hdr section handling.
8. Fix symbol visibility with comdat/linkonce sections in ELF linker.
PR 3666.
9. Fix 4 operand instruction handling in x86 assembler.
10. Properly check the 4th operand in x86 assembler. PR 3712.
11. Fix .cfi_endproc handling in assembler. PR 3607.
12. Various ARM bug fixes.
13. Various PE linker fixes.
14. Improve x86 dissassembler for cmpxchg16b.
Changes from binutils 2.17.50.0.7:
1. Update from binutils 2006 1201.
2. Fix "objcopy --only-keep-debug" crash. PR 3609.
3. Fix various ARM ELF bugs.
4. Fix various xtensa bugs.
5. Update x86 disassembler.
Changes from binutils 2.17.50.0.6:
1. Update from binutils 2006 1127.
2. Properly set ELF output segment address when the first section in
input segment is removed.
3. Better merging of CIEs in linker .eh_frame optimizations.
4. Support .cfi_personality and .cfi_lsda assembler directives.
5. Fix an ARM linker crash. PR 3532.
6. Fix various PPC64 ELF bugs.
7. Mark discarded debug info more thoroughly in lin
