use of %n in genmodes.c causes trouble on Vista
Hello, genmodes.c uses the %n capabilities of printf to compute the width of pieces it outputs. This causes troubles on Windows Vista, because ... << Because of security reasons, support for the %n format specifier is disabled by default in printf and all its variants. ... the default behavior is to invoke the invalid parameter handler ... >> [http://msdn2.microsoft.com/en-us/library/ms175782%28VS.80%29.aspx] It seems to me that we could replace the uses of %n by uses of printf return values. I'm not clear whether this would be considered portable enough, however. Opinions ? Thanks in advance, Olivier
Creating a patch ready for gcc-patches list
Hi,
I am building a cross-compiler for arm, which builds "okay", but the
output is very noisy whilst compiling gcc. I'd like to sort some of it
out and submit some patches, but I've not done any patches for gcc
before so I don't want to create a lot of noise on the gcc-patches list
by posting up patches that are not considered correctly formatted, etc.
At the end of this message is a patch to remove a 'variable might be
used uninitialised' warning which is thrown up whilst bootstrapping gcc.
Is this patch okay to submit to the gcc-patches list?
I haven't touched the ChangeLog, should I fill it in?
Best Regards,
Brian Sidebotham.
--- ./gcc/value-prof.c Mon Jun 4 17:27:14 2007
+++ ./gcc/value-prof.c Wed Jun 6 10:13:20 2007
@@ -883,15 +883,19 @@ tree_mod_subtract (tree stmt, tree opera
e12 = split_block (bb, bb1end);
bb2 = e12->dest;
bb2->count = all - count1;
-
+
if (ncounts) /* Assumed to be 0 or 1. */
{
e23 = split_block (bb2, bb2end);
bb3 = e23->dest;
bb3->count = all - count1 - count2;
+ e34 = split_block (bb3 : bb2, bb3end);
+}
+ else
+{
+ e34 = split_block (bb2, bb3end);
}
- e34 = split_block (ncounts ? bb3 : bb2, bb3end);
bb4 = e34->dest;
bb4->count = all;
Re: Creating a patch ready for gcc-patches list
On 06/06/07, Brian Sidebotham <[EMAIL PROTECTED]> wrote: Hi, I am building a cross-compiler for arm, which builds "okay", but the output is very noisy whilst compiling gcc. I'd like to sort some of it out and submit some patches, but I've not done any patches for gcc before so I don't want to create a lot of noise on the gcc-patches list by posting up patches that are not considered correctly formatted, etc. The problem is not the noise, the problem is taking time from people. The time required to discuss your patch is the same here or in gcc-patches. So if you want to send a good patch: 1) Read http://gcc.gnu.org/contribute.html 2) Look up examples in gcc-patches http://gcc.gnu.org/ml/gcc-patches/ At the end of this message is a patch to remove a 'variable might be used uninitialised' warning which is thrown up whilst bootstrapping gcc. Be more explicit, which line or which variable produces the warning? Is this patch okay to submit to the gcc-patches list? Sorry, it is not. Apart from other things (like changes that only affect to whitespace), your patch must bootstrap and pass the regression testsuite. I have a hunch that the patch below does not bootstrap. I haven't touched the ChangeLog, should I fill it in? You don't need to fill the Changelog file up to the moment when you commit (it is not recommend since it will provoke conflicts when applying the patch). But you need to post the text that you are going to include in the Changelog. Again, look at http://gcc.gnu.org/ml/gcc-patches/ for examples. Let us know if you have any other doubts. It is always hard to get it right the first time. Cheers, Manuel.
Re: Creating a patch ready for gcc-patches list
On Wed, 2007-06-06 10:15:41 -0700, Brian Sidebotham <[EMAIL PROTECTED]> wrote:
> --- ./gcc/value-prof.cMon Jun 4 17:27:14 2007
> +++ ./gcc/value-prof.cWed Jun 6 10:13:20 2007
>
> @@ -883,15 +883,19 @@ tree_mod_subtract (tree stmt, tree opera
>e12 = split_block (bb, bb1end);
>bb2 = e12->dest;
>bb2->count = all - count1;
> -
> +
>if (ncounts) /* Assumed to be 0 or 1. */
> {
>e23 = split_block (bb2, bb2end);
>bb3 = e23->dest;
>bb3->count = all - count1 - count2;
> + e34 = split_block (bb3 : bb2, bb3end);
`-'
First of all, you should compile GCC with your patch applied, and then
run the testsuite. No new regressions should occur (or you should have
a good reason for them!)
> +}
> + else
> +{
> + e34 = split_block (bb2, bb3end);
> }
>
> - e34 = split_block (ncounts ? bb3 : bb2, bb3end);
>bb4 = e34->dest;
>bb4->count = all;
However, this won't even compile, so please redo it, compile it, test
it with the regression suite and submit it with a ChangeLog entry.
(Just plain text, don't prepare it as a patch to the ChangeLog file!)
MfG, JBG
--
Jan-Benedict Glaw [EMAIL PROTECTED] +49-172-7608481
Signature of: Gib Dein Bestes. Dann übertriff Dich selbst!
the second :
signature.asc
Description: Digital signature
Re: Creating a patch ready for gcc-patches list
Hi,
Sorry, wasted your time already!! Thanks to Manuel for the information too.
I will re-patch, compile and run the testsuite. Sorry to waste your time
with my first mail!
Best Regards,
Brian Sidebotham.
Jan-Benedict Glaw wrote:
On Wed, 2007-06-06 10:15:41 -0700, Brian Sidebotham <[EMAIL PROTECTED]> wrote:
--- ./gcc/value-prof.c Mon Jun 4 17:27:14 2007
+++ ./gcc/value-prof.c Wed Jun 6 10:13:20 2007
@@ -883,15 +883,19 @@ tree_mod_subtract (tree stmt, tree opera
e12 = split_block (bb, bb1end);
bb2 = e12->dest;
bb2->count = all - count1;
-
+
if (ncounts) /* Assumed to be 0 or 1. */
{
e23 = split_block (bb2, bb2end);
bb3 = e23->dest;
bb3->count = all - count1 - count2;
+ e34 = split_block (bb3 : bb2, bb3end);
`-'
First of all, you should compile GCC with your patch applied, and then
run the testsuite. No new regressions should occur (or you should have
a good reason for them!)
+}
+ else
+{
+ e34 = split_block (bb2, bb3end);
}
- e34 = split_block (ncounts ? bb3 : bb2, bb3end);
bb4 = e34->dest;
bb4->count = all;
However, this won't even compile, so please redo it, compile it, test
it with the regression suite and submit it with a ChangeLog entry.
(Just plain text, don't prepare it as a patch to the ChangeLog file!)
MfG, JBG
RE: testsuite trigraphs.c failure due to cygwin
On 04 June 2007 23:43, Ian Lance Taylor wrote: > "Timothy C Prince" writes: [ quoting an earlier post of mine ] >> So, am I correct to believe that we need to use plain 'inline' for c99 >> after gcc 4.4, and 'extern inline' before that? That is, I think I need >> to write a test that looks like... >> >> >> #if ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4))) \ >> && defined (__STRICT_ANSI__) && (__STRICT_ANSI__ != 0) \ >> && defined (__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) >> #define ELIDABLE_INLINE inline >> #else >> #define ELIDABLE_INLINE extern inline >> #endif > > No, you shouldn't use anything along those lines. You should check > for __GNUC_GNU_INLINE__ and __GNUC_STDC_INLINE__ as described in the > documentation. > > In fact I mentioned this in my reply to the message you quote above: > http://gcc.gnu.org/ml/gcc/2007-03/msg01093.html > > Ian And I heeded your reply in the patch that eventually got applied to newlib. This test passed when I "make check"ed 4.2.0 RC2. I'll see if I can reproduce the problem. Tim, are you sure you have the patched version of stdio.h in your /usr/include, or are you trying a combined build? cheers, DaveK -- Can't think of a witty .sigline today
Re: use of %n in genmodes.c causes trouble on Vista
In this case, you don't have to look far to see that you can't use the return value of printf. According to my manpage, printf returns 0 on success, 1 on failure. No mention of the number of characters written. This is different with sprintf/snprintf (see e.g http://www.opengroup.org/onlinepubs/95399/functions/snprintf.html), but IIRC a number of platforms don't implement those according to the standard anyway. I suppose that the most portable way to achieve what you want here is to write to a temporary string, then compare the lengths of the temporary strings... Or just add a call to _set_printf_count_output in the relevant place, since AFAIK %n is still a standard-mandated printf format flag. [Shameless *nix zealot plug] Or use a Real Operating System ;-) // Simon On 6/6/07, Olivier Hainque <[EMAIL PROTECTED]> wrote: Hello, genmodes.c uses the %n capabilities of printf to compute the width of pieces it outputs. This causes troubles on Windows Vista, because ... << Because of security reasons, support for the %n format specifier is disabled by default in printf and all its variants. ... the default behavior is to invoke the invalid parameter handler ... >> [http://msdn2.microsoft.com/en-us/library/ms175782%28VS.80%29.aspx] It seems to me that we could replace the uses of %n by uses of printf return values. I'm not clear whether this would be considered portable enough, however. Opinions ? Thanks in advance, Olivier
RE: current gcc trunk testsuite failure on cygwin: Assembler messages: Warning: end of file in string; '"' inserted: Warning: .stabs: missing comma
On 04 June 2007 17:02, Christian Joensson wrote: > configured by ../gcc/configure, generated by GNU Autoconf 2.59, > with options \" '--disable-nls' '--without-included-gettext' > '--enable-version-specific-runtime-libs' '--without-x' > '--disable-libgcj' '--with-system-zlib' '--enable-threads=posix' > '--enable-languages=c,ada,c++,fortran,objc,obj-c++,treelang'\" > and the modified file being (as per D. Korn's suggestion again) > > $ svn status > M libjava/classpath/native/fdlibm/mprec.h That can't be anything to do with it since you aren't building libjava in that configuration and it's nowhere near where the tests are failing. cheers, DaveK -- Can't think of a witty .sigline today
RE: current gcc trunk testsuite failure on cygwin: Assembler messages: Warning: end of file in string; '"' inserted: Warning: .stabs: missing comma
On 05 June 2007 01:57, Tim Prince wrote: > christian.joensson wrote: >> phew, a few of the cygwin failures show up like this: >> >> Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc >> -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c >> -o 20001226-1.o >> /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c >> (timeout = 300) spawn /usr/local/src/trunk/objdir/gcc/xgcc >> -B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o >> 20001226-1.o >> /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c >> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s: Assembler messages: >> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of >> file in string; '"' inserted >> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs: >> missing comma > >> >> Windows XP Pro/SP2 cygwin >> cygwin 1.5.24-2 (with D Korn's stdio.h patch to newlib) > > trigraphs.c also failed for me for the first time, objecting to the > patched version of stdio.h. Is there any reason to suppose these are connected? You didn't mention what kind of error you're seeing yet. cheers, DaveK -- Can't think of a witty .sigline today
RE: use of %n in genmodes.c causes trouble on Vista
On 06 June 2007 12:04, Simon Brenner wrote: > According to my manpage, printf returns 0 on success, 1 on failure. No > mention of the number of characters written. Well, maybe you should ... > use a Real Operating System ! What man page exactly are you referring to? cheers, DaveK -- Can't think of a witty .sigline today
Re: use of %n in genmodes.c causes trouble on Vista
In this case, it's the Mac OS X man page. Which I now see doesn't say the same thing as POSIX. Which was just the point I was trying to make - you can't rely on the return value for determining the number of characters written. Oh, and I am sure the reality of my Operating System is very close to 100% ;-) // Simon On 6/6/07, Dave Korn <[EMAIL PROTECTED]> wrote: On 06 June 2007 12:04, Simon Brenner wrote: > According to my manpage, printf returns 0 on success, 1 on failure. No > mention of the number of characters written. Well, maybe you should ... > use a Real Operating System ! What man page exactly are you referring to? cheers, DaveK -- Can't think of a witty .sigline today
Re: use of %n in genmodes.c causes trouble on Vista
Please don't top-post. Simon Brenner writes: > On 6/6/07, Dave Korn <[EMAIL PROTECTED]> wrote: > > On 06 June 2007 12:04, Simon Brenner wrote: > > > > > According to my manpage, printf returns 0 on success, 1 on failure. No > > > mention of the number of characters written. > > > > Well, maybe you should ... > > > > > use a Real Operating System > > > > ! What man page exactly are you referring to? > In this case, it's the Mac OS X man page. Which I now see doesn't say > the same thing as POSIX. Which was just the point I was trying to make > - you can't rely on the return value for determining the number of > characters written. Yes we can. gcc is written in ISO C, and ISO C says that the printf function returns the number of characters transmitted, or a negative value if an error occurred. We don't support bootstrapping gcc on non-ISO systems. Andrew.
RE: use of %n in genmodes.c causes trouble on Vista
Andrew Haley wrote: > > In this case, it's the Mac OS X man page. Which I now see doesn't > > say the same thing as POSIX. Which was just the point I was > > trying to make you can't rely on the return value for determining > > the number of characters written. > Yes we can. gcc is written in ISO C, and ISO C says that the printf > function returns the number of characters transmitted, or a negative > value if an error occurred. We don't support bootstrapping gcc on > non-ISO systems. Documentation error? They've got the same man page for printf(1) and printf(3): http://www.osxfaq.com/man/1/printf.ws http://www.osxfaq.com/man/3/printf.ws Rup. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
gcj java help
Hello all, How I can import security in gcj java as we used keytool in jdk. Plz give me appropriate guidence. -- Thanks and Regards Sharad Singh Sr. Project Associate EE, IIT Kanpur Mob:+91- 9450 328 117 Accessing Brihaspati: http://202.141.40.217:8080/brihaspati/servlet/brihaspati Login:guest Password: guest Brihaspati learning management system | |(free version) http://sourceforge.net/projects/brihaspati | |(IIT Kanpur installation) http://brihaspati.iitk.ernet.in/ | |Login - guest Password - guest | |(for commercial version with support and maintainence: mail me
RE: use of %n in genmodes.c causes trouble on Vista
> Documentation error? They've got the same man page for printf(1) > and printf(3): Oh, except trying it on a real Mac they don't - that website's broken. Simon, you need to type: man 3 printf to read about printf() the C function. Rup. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: use of %n in genmodes.c causes trouble on Vista
> According to my manpage, printf returns 0 on success, 1 on failure. No > mention of the number of characters written. This is different with > sprintf/snprintf (see e.g > http://www.opengroup.org/onlinepubs/95399/functions/snprintf.html), > but IIRC a number of platforms don't implement those according to the > standard anyway. According to the page you cite, printf and fprintf "shall return the number of bytes transmitted". When Olivier first suggested this, my original thought was the same as yours because I remembered the huge mess in the VAX days with sprintf (does it return int or char *?), but I've looked at lots of man pages (including ancient ones) and can't find anything that says anything else about the return of printf. > I suppose that the most portable way to achieve what you want here is > to write to a temporary string, then compare the lengths of the > temporary strings... Agreed. > Or just add a call to _set_printf_count_output in the relevant > place, since AFAIK %n is still a standard-mandated printf format > flag. Where is the "relevant place"? This would be a really messy host-dependent call and I think it far better to eliminate the usage in *some* way than to do this.
Re: testsuite trigraphs.c failure due to cygwin
[EMAIL PROTECTED] wrote: On 04 June 2007 23:43, Ian Lance Taylor wrote: "Timothy C Prince" writes: [ quoting an earlier post of mine ] So, am I correct to believe that we need to use plain 'inline' for c99 after gcc 4.4, and 'extern inline' before that? That is, I think I need to write a test that looks like... #if ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4))) \ && defined (__STRICT_ANSI__) && (__STRICT_ANSI__ != 0) \ && defined (__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) #define ELIDABLE_INLINE inline #else #define ELIDABLE_INLINE extern inline #endif No, you shouldn't use anything along those lines. You should check for __GNUC_GNU_INLINE__ and __GNUC_STDC_INLINE__ as described in the documentation. In fact I mentioned this in my reply to the message you quote above: http://gcc.gnu.org/ml/gcc/2007-03/msg01093.html Ian And I heeded your reply in the patch that eventually got applied to newlib. This test passed when I "make check"ed 4.2.0 RC2. I'll see if I can reproduce the problem. Tim, are you sure you have the patched version of stdio.h in your /usr/include, or are you trying a combined build? I have patched stdio.h, but it may not be your latest recommendation. The problem didn't show up in gcc-4.3 testsuite until last week.
Re: libjava is a train wreck.
On 6/5/07 12:28 AM, Steve Kargl wrote: > Can someone explain why libjava *must* commit binary files to the > repository? A merge of trunk to the fortran-experiments branch > generated 70 conflicts that I need to resolve. You should not have conflicts in libjava. You may have botched a merger earlier. I never ran into this with the branches I've maintained. Try copying libjava out of trunk again.
RE: testsuite trigraphs.c failure due to cygwin
On 06 June 2007 14:35, Tim Prince wrote: [ artimi dot org removed from Cc: line as it does not exist. ] >> Tim, are you sure you have the patched version of stdio.h in your >> /usr/include, or are you trying a combined build? >> > > I have patched stdio.h, but it may not be your latest recommendation. > The problem didn't show up in gcc-4.3 testsuite until last week. Still don't know what the problem is, though. Could you send me the relevant snippet from gcc.log offlist please? It'll be hours yet before my current running build finishes. cheers, DaveK -- Can't think of a witty .sigline today
RE: segmentation fault
On 05 June 2007 16:49, [EMAIL PROTECTED] wrote: > With apologies for being new: > In porting a hardware configuration from gcc-3.4.1 to gcc-4.2.0, I'm > getting the following error message: > > In file included from /cygdrive/c/gcc-4.2.0/gcc/crtstuff.c:68: > /cygdrive/c/gcc-4.2.0/gcc/tsystem.h:53: internal compiler error: > Segmentation fault. > > Lines 52-54 of tsystem.h are: > > #ifndef malloc > extern void *malloc (size_t); > #endif > > If I remove these lines, all the other extern statements fail also. > What precisely does Segmentation fault mean in this context? Is it > referring to the underlying Windows XP? It's a memory-protection error, usually indicating you have dereferenced a NULL pointer or otherwise tried to access an unmapped memory address. > What sort of compiler, configuration or operating system parameters could > be the cause? > Where should I be looking? Almost certainly your backend is dereferencing a pointer without realising it's NULL at the time. Given the association with extern decls, do you implement a TARGET_ENCODE_SECTION_INFO macro? cheers, DaveK -- Can't think of a witty .sigline today
Re: use of %n in genmodes.c causes trouble on Vista
Olivier Hainque <[EMAIL PROTECTED]> writes: > genmodes.c uses the %n capabilities of printf to compute the width of > pieces it outputs. This causes troubles on Windows Vista, because ... > ><< Because of security reasons, support for the %n format specifier is > disabled by default in printf and all its variants. ... the default > behavior is to invoke the invalid parameter handler ... >>> >[http://msdn2.microsoft.com/en-us/library/ms175782%28VS.80%29.aspx] > > It seems to me that we could replace the uses of %n by uses of printf > return values. I'm not clear whether this would be considered portable > enough, however. What is the security issue here? I'm not seeing it. Are they concerned that attackers will modify the print control string somehow? We've decided that gcc will require an ISO C90 compiler to build. And the behaviour of %n is clearly specified in ISO C90. Actually, it's not quite as clearcut as that, since we haven't necessarily committed to an ISO C90 C library. At least, we still have supporting functions in libiberty which are not required if we can assume an ISO C90 C library. This deficiency is presumably only going to arise for a mingw hosted gcc. Would it be possible for the mingw startup file to call _set_printf_count_output? Perhaps under the control of a command line option at link time? Or, if we think that other systems are likely to also start disabling %n by default, then it would make sense for us to change the code. It would be easy to replace it with strlen calls, or, as you suggest, by checking the return value of printf. The return value of printf is portable (unlike the return value of sprintf). Ian
Re: use of %n in genmodes.c causes trouble on Vista
Simon, you need to type: man 3 printf to read about printf() the C function. Argh! Indeed I was reading the wrong manpage. That probably means almost everything I've concluded and said was wrong :/ Apparently, throwing your two cents in can reduce the total value of a discussion. According to the page you cite, printf and fprintf "shall return the number of bytes transmitted". When Olivier first suggested this, my original thought was the same as yours because I remembered the huge mess in the VAX days with sprintf (does it return int or char *?), but I've looked at lots of man pages (including ancient ones) and can't find anything that says anything else about the return of printf. Perhaps that's just cargo cult portability talking then... > Or just add a call to _set_printf_count_output in the relevant > place, since AFAIK %n is still a standard-mandated printf format > flag. Where is the "relevant place"? This would be a really messy host-dependent call and I think it far better to eliminate the usage in *some* way than to do this. Perhaps it could be something for libiberty to take care of?
Re: When was decimal floating point added to gcc?
On Mon, 4 Jun 2007, H. J. Lu wrote: >> Support for the decimal floating point C extension could be mentioned >> in the release notes for GCC 4.2, but there it's only supported for >> powerpc*-linux and x86*-linux and only if requested at configure time. >> The ABI for powerpc*-linux has changed since then, and the >> representation will (has?) changed for x86*-linux. Is this worth >> documenting for 4.2? > DFP doesn't really work for x86*-linux unitl Uros fixed a bunch > of back-end/middle-end bugs in 4.3. In that case it's probably not that good of a idea to promote it (unless the maintainers are in favor, of course ;-). Gerald
Re: use of %n in genmodes.c causes trouble on Vista
On Wed, Jun 06, 2007 at 07:29:26AM -0700, Ian Lance Taylor wrote:
> Olivier Hainque <[EMAIL PROTECTED]> writes:
>
> > genmodes.c uses the %n capabilities of printf to compute the width of
> > pieces it outputs. This causes troubles on Windows Vista, because ...
> >
> ><< Because of security reasons, support for the %n format specifier is
> > disabled by default in printf and all its variants. ... the default
> > behavior is to invoke the invalid parameter handler ...
> >>>
> >[http://msdn2.microsoft.com/en-us/library/ms175782%28VS.80%29.aspx]
> >
> > It seems to me that we could replace the uses of %n by uses of printf
> > return values. I'm not clear whether this would be considered portable
> > enough, however.
>
> What is the security issue here? I'm not seeing it. Are they
> concerned that attackers will modify the print control string somehow?
There is/was a lot of code that does exactly that, a user can
manipulate the format strings (normally unintentionally, through lazy
coding). http://en.wikipedia.org/wiki/Format_string_attacks
A simple stack overflow might also allow you to write to arbitary
locations in memory. Eg:
int n = 0;
char buf[16] = { 0 };
int* n_ptr = &n;
gets(buf); // might overflow into n_ptr
printf("%s %n", buf, n_ptr);
which basically lets a remote attacker twiddle arbitrary bits in
memory. This looks contrived (and it is), but there have been attacks
against real running systems that exploited code not far off from
this.
(That said disabling %n seems pretty futile, there are many more
obvious ways to write horrible insecure code in C).
-Jack
Re: use of %n in genmodes.c causes trouble on Vista
Or, if we think that other systems are likely to also start disabling
%n by default, then it would make sense for us to change the code. It
would be easy to replace it with strlen calls, or, as you suggest, by
checking the return value of printf. The return value of printf is
portable (unlike the return value of sprintf).
This would be pretty easy:
2007-06-06 Paolo Bonzini <[EMAIL PROTECTED]>
* genmodes.c (tagged_printf, emit_insn_modes_h): Don't
use %n on printf.
Index: genmodes.c
===
--- genmodes.c (revision 125260)
+++ genmodes.c (working copy)
@@ -786,8 +786,7 @@ calc_wider_mode (void)
/* Output routines. */
#define tagged_printf(FMT, ARG, TAG) do { \
- int count_; \
- printf (" " FMT ",%n", ARG, &count_); \
+ int count_ = printf (" " FMT ",", ARG); \
printf ("%*s/* %s */\n", 27 - count_, "", TAG); \
} while (0)
@@ -821,8 +820,7 @@ enum machine_mode\n{");
for (c = 0; c < MAX_MODE_CLASS; c++)
for (m = modes[c]; m; m = m->next)
{
- int count_;
- printf (" %smode,%n", m->name, &count_);
+ int count_ = printf (" %smode,", m->name);
printf ("%*s/* %s:%d */\n", 27 - count_, "",
trim_filename (m->file), m->line);
}
Tested with "make s-modes s-modes-h s-modes-m" and comparing the MD5 of
the *modes*.* files before and after (since the only changes would be in
spacing).
I went ahead and committed this as obvious.
Paolo
Re: use of %n in genmodes.c causes trouble on Vista
Ian Lance Taylor wrote: > What is the security issue here? I'm not seeing it. Are they > concerned that attackers will modify the print control string somehow? I don't know. We simply have observed bootstrap problems during preliminary experiments on Vista, found them to be caused by uninitialized values of "count_" in genmodes and traced this to the %n issue. We have been using a patch almost identical to what Paolo posted, and and I raised the question on gcc@ to see whether this approach was considered correct before performing a formal test-cycle and submission to gcc-patches. [...] > This deficiency is presumably only going to arise for a mingw hosted > gcc. Would it be possible for the mingw startup file to call > _set_printf_count_output? Perhaps under the control of a command line > option at link time? Maybe, I don't know either. The printf-return-value solution just looked straightforward, so that's the first option which came to mind, moderated by the potential portability question. > The return value of printf is portable (unlike the return value of > sprintf). OK, I see Paolo has committed a change along those lines already. Thanks much for your feedback, Olivier
Re: use of %n in genmodes.c causes trouble on Vista
Paolo Bonzini wrote: > * genmodes.c (tagged_printf, emit_insn_modes_h): Don't > use %n on printf. Almost identical to what we have been doing internally to circumvent the issue, Thanks. Olivier
how to build executable instructions blocks dynamically
Hello,
I'm sorry if the answer has already been given, but I haven't found :'(
I want to build executable instructions blocks dynamically, in order to use
the "preparations sequences" in a virtual machine.
I want to create a buffer and to put some code into it.
Until now, I've thought (with some help) about doing this :
---
#include
#include
#include
#include
#include
#include
#include
#include
typedef void (*FUNCTYPE)(void);
void testBuildFunc() {
size_t size = &&block_end - &&block_begin;
#ifndef NOT_MMAP
unsigned char* buf = mmap(NULL, size, PROT_EXEC|PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANON, -1, 0);
if (buf == MAP_FAILED) {
perror("mmap");
exit(EXIT_FAILURE);
}
#else
unsigned char* buf = malloc(size);
if (buf == NULL) {
perror("malloc");
exit(EXIT_FAILURE);
}
if (mprotect(buf,size,PROT_EXEC|PROT_READ|PROT_WRITE) != 0) {
perror("mprotect");
exit(EXIT_FAILURE);
}
#endif
if (buf == MAP_FAILED) {
perror("mmap");
exit(EXIT_FAILURE);
}
unsigned char* beginBuf = buf;
unsigned char* done = &&block_end;
memcpy(buf,&&block_begin,size);
if (msync(block,size,MS_INVALIDATE) != 0) {
perror("msync");
exit(EXIT_FAILURE);
}
int i=1;
FUNCTYPE fn = (FUNCTYPE) beginBuf;
fn();
printf("%d\n",i);
goto *done;
block_begin: {
int j = 0;
}
block_end:
return;
}
I have found an answer using cacheflush... but I haven't managed to install
it on my laptop. (centrino cpu with GNU/Linux os)
If someone could help me, it will help me :-)
Thanks
Regards.
RE: current gcc trunk testsuite failure on cygwin: Assembler messages: Warning: end of file in string; '"' inserted: Warning: .stabs: missing comma
On 04 June 2007 17:02, Christian Joensson wrote:
> phew, a few of the cygwin failures show up like this:
> /usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s: Assembler messages:
> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of
> file in string; '"' inserted
> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs:
> missing comma
> output is:
> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s: Assembler messages:
> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of
> file in string; '"' inserted
> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs:
> missing comma
>
> FAIL: gcc.c-torture/compile/20001226-1.c (test for excess errors)
> Excess errors:
> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of
> file in string; '"' inserted
> /cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs:
> missing comma
>
> and
[Snip similar failures]
It's highly environment sensitive; in a testsuite run, the only one that
failed on me was limits-pointer at -O3, but when I run the compile command
from the shell directly, it fails at any -O level. It looks to me:
Program received signal SIGSEGV, Segmentation fault.
0x004a17fd in dbxout_type_index (type=0x1b1e93c)
at /gnu/gcc/gcc/gcc/dbxout.c:1373
1373 stabstr_D (t->file_number);
(gdb) bt
#0 0x004a17fd in dbxout_type_index (type=0x1b1e93c)
at /gnu/gcc/gcc/gcc/dbxout.c:1373
#1 0x in ?? ()
(gdb) list dbxout_type_index
1362
1363/* Output the index of a type. */
1364
1365static void
1366dbxout_type_index (tree type)
1367{
1368#ifndef DBX_USE_BINCL
1369 stabstr_D (TYPE_SYMTAB_ADDRESS (type));
1370#else
1371 struct typeinfo *t = &typevec[TYPE_SYMTAB_ADDRESS (type)];
(gdb)
1372 stabstr_C ('(');
1373 stabstr_D (t->file_number);
1374 stabstr_C (',');
1375 stabstr_D (t->type_number);
1376 stabstr_C (')');
1377#endif
1378}
... like we're trashing the stack somewhere in the debug output generation.
Hmm, hang on:
(gdb) info regis
eax0x0 0
ecx0x1a0d79027318160
edx0x1b1e93c28436796
ebx0x7fb3b240 2142483008
esp0x42ff0 0x42ff0
ebp0x43008 0x43008
Yeh, that's very wrong: those values should have been 0x0023. Looking
briefly through memory, it seems we've /massively/ underflowed the stack... I
see this repeating pattern that looks a lot like a stack-frame all the way up
from 0x0004 right through memory as far as I could be bothered looking
towards 0x0023.
(gdb)
0x6d200:0x 0x 0x000a 0x
0x6d210:0x7fcc6820 0x 0x 0x0006d27c
0x6d220:0x0020 0x0004 0x0006d288 0x004a0bc4
0x6d230:0x01b06929 0x0006d27c 0x0004 0x
0x6d240:0x 0x 0x 0x
0x6d250:0x 0x 0x 0x
0x6d260:0x 0x 0x 0x
0x6d270:0x 0x 0x 0x33393438
0x6d280:0x7fb38e1c 0x7fb2 0x0006d2a8 0x004a1823
0x6d290:0x 0x 0x 0x7fcc6890
0x6d2a0:0x01b0692f 0x0020 0x0006d388 0x004a42e6
0x6d2b0:0x 0x 0x 0x
0x6d2c0:0x 0x 0x 0x
0x6d2d0:0x 0x 0x 0x
0x6d2e0:0x 0x 0x000a 0x
0x6d2f0:0x7fcc6890 0x 0x 0x0006d35c
0x6d300:0x0020 0x0004 0x0006d368 0x004a0bc4
0x6d310:0x01b0691f 0x0006d35c 0x0004 0x
0x6d320:0x 0x 0x 0x
0x6d330:0x 0x 0x 0x
0x6d340:0x 0x 0x 0x
0x6d350:0x 0x 0x 0x32393438
0x6d360:0x7fb38e10 0x7fb2 0x0006d388 0x004a1823
0x6d370:0x 0x 0x 0x7fcc6900
0x6d380:0x01b06925 0x0020 0x0006d468 0x004a42e6
0x6d390:0x 0x 0x 0x
0x6d3a0:0x 0x 0x 0x
0x6d3b0:0x 0x 0x 0x
0x6d3c0:0x 0x 0x000a 0x
0x6d3d0:0x7fcc6900 0x 0x 0x0006d43c
0x6d3e0:0x00
RE: current gcc trunk testsuite failure on cygwin: Assembler messages: Warning: end of file in string; '"' inserted: Warning: .stabs: missing comma
On 06 June 2007 17:49, Dave Korn wrote: > So, what's happening is that dbxout.c is recursing massively (perhaps to > be expected from a testcase involving pointer-to-pointer-to-pointer-to > pointer-to-int.) Confirmed by relinking cc1.exe with "-Wl,--stack,10240" and seeing that it successfully generates the output source file. cheers, DaveK -- Can't think of a witty .sigline today
[bug] undefined symbols with -Woverloaded-virtual and -fprofile-arcs -ftest-coverage
Hi,
when I build a coverage build of my software I get some undefined symbols
like global constructors keyed to src_utility_Tree.cpp_90B986A5_564B8955
I did some investigation and as you can see in the below test it only occurs
if I specify -Woverloaded-virtual.
What is strange, too is that if I save the preprocessed file (created with
the -E flag) the undefined symbol does NOT show up even if I
use -Woverloaded-virtual
I think this is a bug in g++
/opt2/linux/ix86/x86_64-pc-linux-gnu/bin/g++ --version
g++ (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
for flag in -Wpointer-arith -Woverloaded-virtual -Wcast-align ; do
/opt2/linux/ix86/x86_64-pc-linux-gnu/bin/g++ -o /tmp/Tree-coverage.o \
-c -O0 -g -m32 -D_REENTRANT -DACE_HAS_AIO_CALLS -DACE_USE_RCSID=0 \
-DACE_HAS_EXCEPTIONS -DCOVERAGE -fprofile-arcs -ftest-coverage -fPIC \
-Isrc -I/home/lothar/workspace/tradescapeAPI \
-I/opt2/linux/i686/ACE/1.5.8/ACE_wrappers \
-I/opt2/linux/i686/ACE/1.5.8/ACE_wrappers/TAO \
-I/opt2/linux/i686/ACE/1.5.8/ACE_wrappers/TAO/orbsvcs \
-I/opt2/linux/i686/include -I/opt2/linux/i686/include/boost-1_34 \
-I/opt2/linux/i686/include/python2.5 ${flag} src/utility/Tree.cpp; \
echo; echo ${flag}; nm -u -C /tmp/Tree-coverage.o;
done
-Wpointer-arith
U __cxa_atexit
U __dso_handle
U __gcov_init
U __gcov_merge_add
U _GLOBAL_OFFSET_TABLE_
U __gxx_personality_v0
U std::ios_base::Init::Init()
U std::ios_base::Init::~Init()
-Woverloaded-virtual
U __cxa_atexit
U __dso_handle
U __gcov_init
U __gcov_merge_add
U global constructors keyed to
src_utility_Tree.cpp_90B986A5_564B8955
U _GLOBAL_OFFSET_TABLE_
U __gxx_personality_v0
U std::ios_base::Init::Init()
U std::ios_base::Init::~Init()
-Wcast-align
U __cxa_atexit
U __dso_handle
U __gcov_init
U __gcov_merge_add
U _GLOBAL_OFFSET_TABLE_
U __gxx_personality_v0
U std::ios_base::Init::Init()
U std::ios_base::Init::~Init()
Lothar
Re: how to build executable instructions blocks dynamically
On Jun 6, 2007, at 9:43 AM, Gorgonite wrote: I'm sorry if the answer has already been given, but I haven't found :'( Yes, it has, google will find it too... :-) I want to build executable instructions blocks dynamically Wrong list... You want a list that has something to do with the OS you intend to run on.
Re: use of %n in genmodes.c causes trouble on Vista
Robert Dewar writes: > Andrew Haley wrote: > > > Yes we can. gcc is written in ISO C, and ISO C says that the printf > > function returns the number of characters transmitted, or a negative > > value if an error occurred. We don't support bootstrapping gcc on > > non-ISO systems. > > Well ISO C also says that %n works, let's be a bit more pragmatic > here I think ... no point in using something we know is widely > problematic. Mmm, but I don't believe that the printf function returning the number of characters transmitted is problematic. As far as we know, that works everywhere. The only thing to say otherwise is a man page. My guess is the man page is wrong. Andrew.
dataflow branch merge plans.
At this point the entire branch has been reviewed by Ian Taylor. It is expected that all of the changes that he has asked for will be committed either tonight or tomorrow. Danny Berlin will do another merge with the trunk tonight and we will test that. As of last week, the dataflow branch was clean on x86-32, x86-64, spu, mips, arm and sh. There is one ia-64 regression with "make profiledbootstrap" There are a small number of ppc libjava regressions. Sparc has a pending patch, when that is reviewed, the sparc will be clean. pa-risc has a pending patch, when that is reviewed it will at least bootstrap. The regression tests are still running. alpha bootstraps, no regressions have been run. m68k is in progress. bonzini and zippel are negotiating changes to make it work. It is our plan to commit the branch on monday June 11. Hopefully in the morning on the us east coast. This depends on the trunk working at that time. To make this process easier, we ask that people hold off committing large patches, especially to the rtl passes on that day. The dataflow branch does not touch the tree level, nor the front ends. Kenny
RE: use of %n in genmodes.c causes trouble on Vista
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Simon Brenner > Sent: Thursday, 7 June 2007 2:40 a.m. > > > Or just add a call to _set_printf_count_output in the relevant > > > place, since AFAIK %n is still a standard-mandated printf format > > > flag. > > > > Where is the "relevant place"? This would be a really > messy host-dependent > > call and I think it far better to eliminate the usage in > *some* way than > > to do this. > > Perhaps it could be something for libiberty to take care of? Unless I'missing soemthing, this is 'just' a build issue in genmode.c. GCC builds fine for Vista target on WindowsXP. So the fix needs to be build dependent, not host dependent. Danny
Re: use of %n in genmodes.c causes trouble on Vista
Andrew Haley wrote: Mmm, but I don't believe that the printf function returning the number of characters transmitted is problematic. As far as we know, that works everywhere. The only thing to say otherwise is a man page. My guess is the man page is wrong. OK, I misunderstood the situation, indeed if that works everywhere, it is perfectly fine! Andrew.
Re: When was decimal floating point added to gcc?
On Wed, 2007-06-06 at 16:46 +0200, Gerald Pfeifer wrote: > In that case it's probably not that good of a idea to promote it (unless > the maintainers are in favor, of course ;-). I'm happy to leave things as they are for now. Cheers, Ben -- Ben Elliston <[EMAIL PROTECTED]> Australia Development Lab, IBM
Re: use of %n in genmodes.c causes trouble on Vista
Danny Smith wrote: Unless I'missing soemthing, this is 'just' a build issue in genmode.c. GCC builds fine for Vista target on WindowsXP. So the fix needs to be build dependent, not host dependent. Well if a clean fix can be found that simply avoids the use of %n, then that's target independent and clean. I think that makes sense. The idea that %n is a security risk is not some Microsoft-only invention, and it is not unlikely that other environments will implement a similar check. Danny
gcc-4.2-20070606 is now available
Snapshot gcc-4.2-20070606 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070606/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 125507 You'll find: gcc-4.2-20070606.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20070606.tar.bz2 C front end and core compiler gcc-ada-4.2-20070606.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20070606.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20070606.tar.bz2 C++ front end and runtime gcc-java-4.2-20070606.tar.bz2 Java front end and runtime gcc-objc-4.2-20070606.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20070606.tar.bz2The GCC testsuite Diffs from 4.2-20070530 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: libjava is a train wreck.
On Wed, 2007-06-06 at 08:29 -0400, Diego Novillo wrote: > You should not have conflicts in libjava. You may have botched a merger > earlier. I never ran into this with the branches I've maintained. Try > copying libjava out of trunk again. Out of interest, what happens if you have svn file properties that are changed in both branches? Will that lead to a merge conflict? Ben
Re: use of %n in genmodes.c causes trouble on Vista
Danny Smith wrote: Unless I'missing soemthing, this is 'just' a build issue in genmode.c. GCC builds fine for Vista target on WindowsXP. So the fix needs to be build dependent, not host dependent. Well if a clean fix can be found that simply avoids the use of %n, then that's target independent and clean. I think that makes sense. The idea that %n is a security risk is not some Microsoft-only invention, and it is not unlikely that other environments will implement a similar check. In case you have not seen it, this is the bit of code we are talking about :- http://git.infradead.org/?p=gcc.git;a=blob;f=gcc/genmodes.c;h=8e71a123edb46166a16971bbf1862c2a0cfcf1b9;hb=master#l788 I think a sprintf followed by a strlen and printf is _guarenteed_ to be much more portable than printf's return value. The overhead of the strlen is minimal. A simple fix that works on all platforms is all that is required. Aaron
Re: [bug] undefined symbols with -Woverloaded-virtual and -fprofile-arcs -ftest-coverage
On Wed, Jun 06, 2007 at 11:13:16AM -0700, Lothar Werzinger wrote: > when I build a coverage build of my software I get some undefined symbols > like global constructors keyed to src_utility_Tree.cpp_90B986A5_564B8955 > > I did some investigation and as you can see in the below test it only occurs > if I specify -Woverloaded-virtual. > > What is strange, too is that if I save the preprocessed file (created with > the -E flag) the undefined symbol does NOT show up even if I > use -Woverloaded-virtual > > I think this is a bug in g++ Sounds like it. I suggest that you file a bug report, with a complete testcase, so that it can be fixed.
Re: use of %n in genmodes.c causes trouble on Vista
> I think a sprintf followed by a strlen and printf is _guarenteed_ to be much > more portable than printf's return value. The overhead of the strlen is > minimal. Maybe portable, but how do you choose the length of the buffer to pass to sprintf! Ironic: we'd be trading a mostly-bogus security issue for a buffer overflow problem.
Re: use of %n in genmodes.c causes trouble on Vista
I think a sprintf followed by a strlen and printf is _guarenteed_ to be much more portable than printf's return value. The overhead of the strlen is minimal. Maybe portable, but how do you choose the length of the buffer to pass to sprintf! Ironic: we'd be trading a mostly-bogus security issue for a buffer overflow problem. snprintf (from libiberty) ? we should maybe check the maximum length of identifiers anyway ? This thing is really trivial security wise anyway. Aaron
