Re: Some Tests in gcc.dg/graphite/ are failing for AVR target
On 03/28/2014 03:52 PM, K_s, Vishnu wrote: Hi all, Some of the tests added in gcc.dg/graphite are failing for AVR target, Because size of the arrays defined are 'too' large for AVR. I'm wondering is it possible to reduce the size of the array's in tests. One example is gcc.dg/graphite/scop-0.c, which is failing with error "size of array 'a' is too large" when compiling with avr-gcc. Following tests are also failing for avr-gcc with error "size of array used is too large". gcc.dg/graphite/scop-22.c gcc.dg/graphite/scop-3.c gcc.dg/graphite/scop-dsyr2k.c gcc.dg/graphite/scop-dsyrk.c gcc.dg/graphite/scop-mvt.c gcc.dg/graphite/scop-sor.c gcc.dg/graphite/pr46185.c Hi Vinshnu, could you provide a patch that fixes these tests for your platform by reducing array sizes. It makes the intention very clear and we could just review it. (I am almost certain it is trivial to accept). Cheers, Tobias
[patch] Fix texinfo warnings for doc/gcc.texi [was: Re: doc bugs]
H.J. Lu wrote:
On Fri, Mar 28, 2014 at 12:41 PM, Mike Stump wrote:
Since we are nearing release, I thought I'd mention I see:
../../gcc/gcc/doc/invoke.texi:1114: warning: node next `Overall Options' in
menu `C Dialect Options' and in sectioning `Invoking G++' differ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59055
I think one reason that there are (and were) that many warnings is that
only recently texinfo gained support for diagnosing these issues. (Or
maybe not that recent but distributions were slow in adapting newer
texinfo versions.)
Attached is a warning-removal patch.
OK for the trunk?
Regarding invoke.texi: It had (nearly) the same @menu twice, once under
@chapter where it belongs to and once under a @section where it doesn't.
Tobias
2014-03-29 Tobias Burnus
PR other/59055
* doc/bugreport.texi (Bugs): Remove nodes pointing to the
nirvana.
* doc/gcc.texi (Service): Update description in the @menu
* doc/invoke.texi (Option Summary): Remove misplaced and
duplicated @menu.
diff --git a/gcc/doc/bugreport.texi b/gcc/doc/bugreport.texi
index be03522..e465c24 100644
--- a/gcc/doc/bugreport.texi
+++ b/gcc/doc/bugreport.texi
@@ -16,11 +16,9 @@ report the problem.
@menu
* Criteria: Bug Criteria. Have you really found a bug?
* Reporting: Bug Reporting. How to report a bug effectively.
-* Known: Trouble.Known problems.
-* Help: Service. Where to ask for help.
@end menu
-@node Bug Criteria,Bug Reporting,,Bugs
+@node Bug Criteria
@section Have You Found a Bug?
@cindex bug criteria
@@ -83,7 +81,7 @@ If you are an experienced user of one of the languages GCC supports, your
suggestions for improvement of GCC are welcome in any case.
@end itemize
-@node Bug Reporting,,Bug Criteria,Bugs
+@node Bug Reporting
@section How and where to Report Bugs
@cindex compiler bugs, reporting
diff --git a/gcc/doc/gcc.texi b/gcc/doc/gcc.texi
index 1e0fc46..c1f3857 100644
--- a/gcc/doc/gcc.texi
+++ b/gcc/doc/gcc.texi
@@ -140,7 +140,7 @@ Introduction, gccint, GNU Compiler Collection (GCC) Internals}.
* Gcov::@command{gcov}---a test coverage program.
* Trouble:: If you have trouble using GCC.
* Bugs::How, why and where to report bugs.
-* Service:: How to find suppliers of support for GCC.
+* Service:: How To Get Help with GCC
* Contributing::How to contribute to testing and developing GCC.
* Funding:: How to help assure funding for free software.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 78ddde0..b623b05 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1088,28 +1088,6 @@ See S/390 and zSeries Options.
-fvisibility -fstrict-volatile-bitfields -fsync-libcalls}
@end table
-@menu
-* Overall Options:: Controlling the kind of output:
-an executable, object files, assembler files,
-or preprocessed source.
-* C Dialect Options:: Controlling the variant of C language compiled.
-* C++ Dialect Options:: Variations on C++.
-* Objective-C and Objective-C++ Dialect Options:: Variations on Objective-C
-and Objective-C++.
-* Language Independent Options:: Controlling how diagnostics should be
-formatted.
-* Warning Options:: How picky should the compiler be?
-* Debugging Options:: Symbol tables, measurements, and debugging dumps.
-* Optimize Options::How much optimization?
-* Preprocessor Options:: Controlling header files and macro definitions.
- Also, getting dependency information for Make.
-* Assembler Options:: Passing options to the assembler.
-* Link Options::Specifying libraries and so on.
-* Directory Options:: Where to find header files and libraries.
-Where to find the compiler executable files.
-* Spec Files:: How to pass switches to sub-processes.
-* Target Options:: Running a cross-compiler, or an old version of GCC.
-@end menu
@node Overall Options
@section Options Controlling the Kind of Output
slides of talk on "GCC plugins thru the MELT example" (Linux F. Collab. S)
Dear All,
I gave a talk on "GCC plugins thru the MELT example" at the Linux
Foundation Collaboration Summit (Friday, March 28th 2014, Napa Valley,
California, USA)
http://events.linuxfoundation.org/events/collaboration-summit/
The slides of my talk are available online at
http://gcc-melt.org/gcc-plugin-MELT-LinuxCollabSummit2014.pdf
There should be useful to anyone interested
in GCC plugins or MELT extensions
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Could we harden GCC's stack smashing? (Re: Adam Zabrocki's Adventure with stack smashing protection)
Hello,
Adam Zabrocki's Adventure with stack smashing protection at
(http://blog.pi3.com.pl/?p=485 ) is kind of interesting. It lists some possible
weaknesses in GCC's -fstack-protector. Given that the weaknesses happen when the
stack has already been smashed I do not think they are critical but they do bug
me. I think that the issues happen due to the fundamental problem with the
approach that GCC's reporting method is taking. Instead of dealing with the
messed up state of the process it could exec a whole new process or simply
abort. We could also actually raise our own SIGSEGV signal. I coded up a small
illustration of how the exec strategy would work.
Thank you,
Steven Stewart-Gallus
#include
#include
#include
#include
/*
* In a real implementation this would be a real crash reporting
* program. It would use /proc to examine debugging information such
* as the command line. It could also do ptrace debugger stuff. It
* could also be set by a command line option.
*/
#define CRASH_REPORTER "/bin/echo"
void stack_overflow(void);
int main()
{
stack_overflow();
}
void stack_overflow(void)
{
/*
* As soon as possible give control over to a fresh crash reporter
* instance. If any bad things happen abort immmediately and don't
* risk compromise due to an attack from an enemy.
*/
/*
* Fork a copy of the program to be debugged from the crash
* reporter instance. The copy of the program must be the child
* because certain systems are hardened to only allow parents of
* the processes to do certain debugging tasks.
*/
pid_t child = fork();
if (-1 == child) {
abort();
}
if (0 == child) {
raise(SIGSTOP);
abort();
}
/* Don't bother with sprintf to minimize the chance of attacks. */
char child_string[sizeof child + 1];
memcpy(child_string, &child, sizeof child);
child_string[sizeof child] = '\0';
/*
* execve the crash reporter to use the thinnest possible wrapper
* over the system call.
*/
char * argv[] = {
(char *) CRASH_REPORTER,
child_string,
NULL
};
char * envp[] = { NULL };
execve(CRASH_REPORTER, argv, envp);
abort();
}
RL78 sim?
Hi, So far I've been testing with hardware but I'm pretty sure I read somewhere about an RL78 simulator, which would be a useful addition. Does this simulator exist, and if so, how do I run the tests against it? I tried 'make -k check RUNTESTFLAGS="--target_board=rl78-sim"' but in amongst the errors I see 'ERROR: couldn't load description file for rl78-sim', either it has a different name or I'm missing something on my system (and a quick search didn't seem to find anything but I don't really know what I'm looking for). Regards, Richard.
Re: Could we harden GCC's stack smashing? (Re: Adam Zabrocki's Adventure with stack smashing protection)
On Sat, Mar 29, 2014 at 10:52 AM, Steven Stewart-Gallus wrote: > > Adam Zabrocki's Adventure with stack smashing protection at > (http://blog.pi3.com.pl/?p=485 ) is kind of interesting. It lists some > possible > weaknesses in GCC's -fstack-protector. Given that the weaknesses happen when > the > stack has already been smashed I do not think they are critical but they do > bug > me. I think that the issues happen due to the fundamental problem with the > approach that GCC's reporting method is taking. Instead of dealing with the > messed up state of the process it could exec a whole new process or simply > abort. We could also actually raise our own SIGSEGV signal. I coded up a small > illustration of how the exec strategy would work. Thanks. The code in question is actually part of glibc, not GCC. All GCC does is call __stack_chk_fail. You may want to take your concerns to the glibc developers--see http://sourceware.org/glibc. GCC does have it's own copy of __stack_chk_fail in libssp, but it's simpler than the glibc version. Ian
gcc-4.7-20140329 is now available
Snapshot gcc-4.7-20140329 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20140329/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 208941 You'll find: gcc-4.7-20140329.tar.bz2 Complete GCC MD5=254645e6e7717fad812a0ad032e9fd03 SHA1=b68681f9b7f33e13ca464e78e18fdc41b5ba21f5 Diffs from 4.7-20140322 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 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: Could we harden GCC's stack smashing? (Re: Adam Zabrocki's Adventure with stack smashing protection)
Thank you, I must then apologize to the GCC mailing list for bringing up something off topic. About GCC's _stack_chk_fail. Yeah, it's much simpler. Personally, I wouldn't trust syslog but I'm not sure of a good alternative. I'll go bother the GLibc people. Thank you, Steven Stewart-Gallus P.S. I'm not sure if the write to the terminal should handle EINTR. I know for pipes that EINTR doesn't happen on Linux but I have no idea for the /dev/tty special file. - Original Message - From: Ian Lance Taylor Date: Saturday, March 29, 2014 1:03 pm Subject: Re: Could we harden GCC's stack smashing? (Re: Adam Zabrocki's Adventure with stack smashing protection) To: Steven Stewart-Gallus Cc: GCC Development > On Sat, Mar 29, 2014 at 10:52 AM, Steven Stewart-Gallus > wrote: > > > > Adam Zabrocki's Adventure with stack smashing protection at > > (http://blog.pi3.com.pl/?p=485 ) is kind of interesting. It lists > some possible > > weaknesses in GCC's -fstack-protector. Given that the weaknesses > happen when the > > stack has already been smashed I do not think they are critical > but they do bug > > me. I think that the issues happen due to the fundamental problem > with the > > approach that GCC's reporting method is taking. Instead of > dealing with the > > messed up state of the process it could exec a whole new process > or simply > > abort. We could also actually raise our own SIGSEGV signal. I > coded up a small > > illustration of how the exec strategy would work. > > Thanks. The code in question is actually part of glibc, not GCC. All > GCC does is call __stack_chk_fail. You may want to take your concerns > to the glibc developers--see http://sourceware.org/glibc. > > GCC does have it's own copy of __stack_chk_fail in libssp, but it's > simpler than the glibc version. > > Ian >
