Unwinding through exception handlers when PC is NULL.
Consider this program under GNU/Linux (x86_64):
- np.c ---
#include
#include
#include
#include
static void handler(int sig)
{
printf("got signal %d\n", sig);
throw 1;
}
int (*my_vector)(int);
int *bar;
int main(int argc, char *argv[])
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_handler = handler;
sa.sa_flags = SA_RESTART;
sigemptyset(&sa.sa_mask);
int rv = sigaction(SIGSEGV, &sa, NULL);
if (rv) {
perror("sigaction failed");
exit(1);
}
try {
//*bar = 6;
rv = my_vector(0);
} catch (int c) {
printf("I cought %d\n", c);
exit(0);
}
printf("No exception\n");
return 0;
}
--8<-
$ g++ -fnon-call-exceptions -o np np.cc
$ ./np
got signal 11
terminate called after throwing an instance of 'int'
Aborted (core dumped)
However if we uncomment the '//*bar = 6;' line we get:
$ ./np
got signal 11
I cought 1
This happens because the libgcc unwinder cannot find unwinding
information for the PC at the point of the SIGSEGV.
However, we know that usually when we end up with a PC of zero, it is
because we called through a NULL function pointer. In this case, we
could use the return address (perhaps with a slight adjustment to
compensate for the call instruction) to do the unwinding.
Would it make any sense to build something like this into libgcc?
Or if we want to do this do we need to patch up the register state
before executing the throw?
David Daney
Re: Integration of transactional memory support into a data-flow extension of OpenMP
On Wed, 2011-05-04 at 12:03 +0200, Patrick Marlier wrote: ---Sorry for the late response. > Dear Ismail, > > On 05/03/2011 11:18 PM, ismail wrote: > >> ++ First of all, MEMCPY and MEMSET functions do not include any > >> transaction identifier (id) and transactions inside the LeeTM fails > >> during transactional access to the memory. I think this case is also > >> for tinySTM-0.9.9 and tinySTM-1.0. > >> > >> ++ tinySTM-0.9.9 has mem access functions with transaction handlers as > >> the following > >> ++stm_word_t stm_load(stm_tx_t *tx, volatile stm_word_t *addr); > >> ++void stm_store(stm_tx_t *tx, volatile stm_word_t *addr, stm_word_t > >> value); > >> ++void stm_store2(stm_tx_t *tx, volatile stm_word_t *addr, stm_word_t > >> value, stm_word_t mask); > >> > >> > >> ++but tinySTM-1.0 does not . Your opinions on these different version > >> of mem-access functions would be great. > > TinySTM 1.0 uses implicit transaction descriptor by default (same as > 0.9.9) but you can compile it with EXPLICIT_TX_PARAMETER (Makefile) and > then the transaction descriptor is explicit. > But functions are the same from 0.9.9 to 1.0.0 so I don't really see the > problem. --- Yes . thanks for update , I remembered . Also I wrote the version wrong it is "0.9.0b1 release". There should be a parameter like EXPLICIT_TX_PARAMETER in trans-mem. Did you need a kind of parameter --- while compiling the trans-mem branch ? For example to use trans-mem to transactify LeeTM (I am especially talking about the MEMSET and MEMCPY funcs. of trans-mem do not have transaction identifier while accessing to the mem.). --- I am currently using the explicit function calls when I need transaction identifier as the following. > >> ++My idea to convert from one version of mem-access function to > >> another is as the following: > >> > >> > >> ++ I think I have to make some explicit function calls as the > >> following: > >> ++ _ITM_transaction * td = _ITM_getTransaction(); > >> ++int doWhat = > >> _ITM_beginTransaction(td,pr_instrumentedCode,&txn_start_loc); > >> ++ . > >> ++_ITM_transactionId cur_id = _ITM_getTransactionId(); > > I do not understand that... > --- I tried to get transaction handler which does not ---have explicit ---descriptor where another function needs transaction ---descriptor as ---a parameter. > >> ++ Of course , It would be great to share the study and results with > >> you when I organize my study and all other things. > > I guess we will meet together at the EuroTM meeting in Paris. > ---Yes that will be great for me to have a chance to talk and discuss topics with you > Patrick Marlier. ---Ismail KURU
gcc-4.5-20110505 is now available
Snapshot gcc-4.5-20110505 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20110505/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 173458 You'll find: gcc-4.5-20110505.tar.bz2 Complete GCC (includes all of below) MD5=7714ae4d63e20f3f35446f08f18a702f SHA1=550d4d1241d0583c4143683502c3581af88a0bf7 gcc-core-4.5-20110505.tar.bz2C front end and core compiler MD5=a74f60182cd51439838d6a981b624331 SHA1=5e817e259b04e494a2e358f2c5729ecccd18a2f3 gcc-ada-4.5-20110505.tar.bz2 Ada front end and runtime MD5=48c9e50878b807240b0b72732e66b5a0 SHA1=45d6483c7daa633cad0becd297babe894dcd6269 gcc-fortran-4.5-20110505.tar.bz2 Fortran front end and runtime MD5=897740c419f380011a8f91485f4f81e8 SHA1=5b104f2f864f3016f2f13c24421dfe50b7a5ccc7 gcc-g++-4.5-20110505.tar.bz2 C++ front end and runtime MD5=08de316d0612245775c6e7e6985dfa32 SHA1=2a34de91d5d585360a532b9405c7bbd40d40d307 gcc-go-4.5-20110505.tar.bz2 Go front end and runtime MD5=d27fb9e3844beb184c77ae8ee29ce6d6 SHA1=7bd2cd7a38d99a635de0aadbc087759e14c89831 gcc-java-4.5-20110505.tar.bz2Java front end and runtime MD5=31bcce8442d9036321c836144458f51d SHA1=880e8a0ed148ea99350c7df3104e9059b9901bdf gcc-objc-4.5-20110505.tar.bz2Objective-C front end and runtime MD5=91bfe8f5bc32093ad7f8b3745a826d08 SHA1=e5e9318a9d40dcbc4f2fd3566430625039b324f2 gcc-testsuite-4.5-20110505.tar.bz2 The GCC testsuite MD5=fa4055cdcd8afd14c9cdc62eaf946725 SHA1=3ae3272a86f7039bf075e5289add3823749f27d3 Diffs from 4.5-20110428 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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: gcc detect multiple -o passed on one command line
Bernd Schmidt writes: > On 05/05/2011 11:53 PM, Ian Lance Taylor wrote: >> Jon Grant writes: >> >>> Is it expected that more than one -o option should be allowed by GCC >>> on command line? The later -o option overriding earlier. >> >> Yes, this is expected. Most Unix utilities behave that way: when an >> option with an argument is specified twice, and it only makes sense to >> specify it once, then the option argument which comes last is used. > > Huh. If you add -E to the command line you get > > cc1: error: output filename specified twice > > so we're a little inconsistent here. Hmmm, you're right. I tend to think it is a bug to give an error here, but I don't feel strongly about it. The difference is that with -E the -o option is passed to cc1, whereas without it the -o option is passed to the assembler or the linker. The GNU assembler and linker both have the usual Unix behaviour of only using the last -o option. Ian
Re: gcc detect multiple -o passed on one command line
On 05/05/2011 11:53 PM, Ian Lance Taylor wrote: > Jon Grant writes: > >> Is it expected that more than one -o option should be allowed by GCC >> on command line? The later -o option overriding earlier. > > Yes, this is expected. Most Unix utilities behave that way: when an > option with an argument is specified twice, and it only makes sense to > specify it once, then the option argument which comes last is used. Huh. If you add -E to the command line you get cc1: error: output filename specified twice so we're a little inconsistent here. Bernd
Re: 'The GNU Compiler for the JavaTM Programming Language' translation
On Thu, May 05, 2011 at 11:33:44AM -0700, Paul Koning wrote: > It sounds to me like the question "are you allowed to translate this" remains > valid and open, even if this particular translator is not real. Yes, the SC's discussing it with RMS now and I'm hopeful that there will be some positive changes made (too early to say more than that).
Re: gcc detect multiple -o passed on one command line
Jon Grant writes: > Is it expected that more than one -o option should be allowed by GCC > on command line? The later -o option overriding earlier. Yes, this is expected. Most Unix utilities behave that way: when an option with an argument is specified twice, and it only makes sense to specify it once, then the option argument which comes last is used. Ian
Re: GAS GCC FAQ query
On 5 May 2011 22:30, Jon Grant wrote: > Hello > > Just looking at this page: > > http://gcc.gnu.org/faq.html#gas > > I saw this text "(the GNU loader)". Is this really an alternative name > for gas? I've not seen it called GNU loader elsewhere. I was wondering > if the text could just be removed. It refers to the linker, ld, not to gas, and shouldn't be removed. The parenthesized text represents an alternation, the paragraph should be read as referring to the GNU assembler or to the the GNU linker (aka loader).
gcc detect multiple -o passed on one command line
Hello Is it expected that more than one -o option should be allowed by GCC on command line? The later -o option overriding earlier. I had expected the parameter checking to detect this duplication of options. gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 $ gcc -W -Wall -o main main.c -omup.o $ ls main.c mup.o I can create a bug ticket if needed. Let me know. Please keep my email address included in any replies. Best regards, Jon
GAS GCC FAQ query
Hello Just looking at this page: http://gcc.gnu.org/faq.html#gas I saw this text "(the GNU loader)". Is this really an alternative name for gas? I've not seen it called GNU loader elsewhere. I was wondering if the text could just be removed. Please keep my email address in any replies. Best regards, Jon
Re: [gimplefe] Merge from trunk rev 173770
er, wrong subject. I merged up to rev 173270. Diego.
[gimplefe] Merge from trunk rev 173770
This merge brings the gimple-front-end branch up to 4.7. It needed some minimal adjustments, but things seem to be working. Sandeep, please make sure it does. You may need to rebase your patch before committing it. We need some tests in testsuite/gimple. Sandeep, do you think you could add some? If you need a hand with dejagnu, let me know. We still cannot generate code, but we should start adding some minimal parsing tests. Diego.
Re: [MELT] a successful compilation of GCC using a plugin
On 05/05/2011 21:46, Diego Novillo wrote: On Thu, May 5, 2011 at 15:16, Diego Novillo wrote: I've always found MELT interesting as an exercise in impossibility and [ ... ] There was some confusion about my meaning here. It was meant as a compliment. Sorry for the confusion. Diego. Yeah, Basile's work is very impressive. From what I can say (Basile might answer better), the idea is to offer more and more abstraction in order to manipulate as easily as possible the GCC structures. In particular, MELT emphasizes on offering rich pattern matching features (on tree, gimple...). On a (very?) long term view, we could imagine a language centered on pattern matching request, helping the user to extract informations (such has "return every basic block that contains a call to foo()").
Re: [MELT] a successful compilation of GCC using a plugin
On Thu, May 5, 2011 at 15:16, Diego Novillo wrote: > I've always found MELT interesting as an exercise in impossibility and > [ ... ] There was some confusion about my meaning here. It was meant as a compliment. Sorry for the confusion. Diego.
Re: [MELT] a successful compilation of GCC using a plugin
On Thu, May 5, 2011 at 12:53, Pierre Vittet wrote: > Hello, > > I would like to announce that I have been able to compile GCC while checking > it with a simple MELT plugin that I have wrote. This plugin is integrated > into GCC by using the MELT plugin. I guess this is the first successfull use > of MELT with a huge real program like GCC. > > For those who are not really aware about MELT and how it works: > MELT is available into 2 forms: > -A GCC branch > -A GCC plugin > > Here I have use MELT as a GCC plugin. > > This GCC plugin loads a melt.so library which has severals modes. > Firstly I have use the translatetomodule mode. This mode allows me to > translate my plugin (which is a file "test_fopen.melt") into several C files > and then into a dynamic test_fopen.so. Congratulations! I've always found MELT interesting as an exercise in impossibility and I'm very impressed at how far you folks have gotten. I would've never thought that it would be possible to write this kind of plugin given the lack of proper interfaces. Keep it up! If nothing else, I think we should use something like MELT to improve plugin support in the compiler. Do you have any plans for MELT to produce some set of static analyzers that people can use off-the-shelf? Diego.
[MELT] a successful compilation of GCC using a plugin
Hello,
I would like to announce that I have been able to compile GCC while
checking it with a simple MELT plugin that I have wrote. This plugin is
integrated into GCC by using the MELT plugin. I guess this is the first
successfull use of MELT with a huge real program like GCC.
For those who are not really aware about MELT and how it works:
MELT is available into 2 forms:
-A GCC branch
-A GCC plugin
Here I have use MELT as a GCC plugin.
This GCC plugin loads a melt.so library which has severals modes.
Firstly I have use the translatetomodule mode. This mode allows me to
translate my plugin (which is a file "test_fopen.melt") into several C
files and then into a dynamic test_fopen.so.
The command is the following:
gcc
-fplugin=/usr/lib64/gcc/x86_64-mandriva-linux-gnu/4.6.0/plugin/melt.so \
-fplugin-arg-melt-mode=translatetomodule \
-fplugin-arg-melt-arg=/home/mpierre/programmation/melt/test_fopen/test_fopen.melt
\
-c empty.c 2>fopen_compil_debug.txt
The second step is to compile GCC using CFLAGS which define that we use
the MELT plugin with the mode test_fopen which is defined in my plugin
and precising the location of the test_fopen.so. This allows me to
execute the pass defined in my plugin.
The command is the following:
make CFLAGS="-fplugin=/usr/lib64/gcc/x86_64-mandriva-linux-
gnu/4.6.0/plugin/melt.so -fplugin-arg-melt-mode=test_fopen
-fplugin-arg-melt-init=@@:test_fopen
-fplugin-arg-melt-module-path=$build
-fplugin-arg-melt-source-path=$build -Wno-error"
What does my test_fopen.melt plugin?
It searchs each call to the fopen function and get the lhs (under the
form of a tree).
After the fopen calls, it looks at the next gimple. If this not a
gimple_cond_equal or gimple_cond_notequal between the lhs of the call
and NULL, it returns a warning, explaining that the call was not tested.
This is not perfect for now, it can find some false positifs, in some
special cases, like this one:
s->file = fd < 0 ? F_OPEN(path, fmode) : (FILE*)fdopen(fd, fmode);
if (s->file == NULL) {
...
}
...
It comes from the fact, that at GIMPLE state, the expression is separate
into severals and the test is not made immediatly but after a few gimples.
However, it sends also some pertinents warnings:
-in gcc/gcc.c line 3422, function driver_handle_option:
There is a call to fopen without test, I don't know much about what it
does but can we be sure that the fopen always return somethings not NULL.
note: in reality this is not the fopen function but the fopen_unlocked
function which is called at this step (using a #define). I have adapted
my plugin to search also for fopen_unlocked which call fopen without
testing more the returned value.
-in libcpp/files.c line 1468, function read_name_map:
there is another call to the fopen function.
The full log of my GCC compilation can be found here:
http://pvittet.com/GSOC/log.txt .
The plugin that I have written can be found here:
https://github.com/Piervit/GMWarn/tree/master/test_fopen .
If you have any questions or remarks, I would be glad to read them :)
Re: 'The GNU Compiler for the JavaTM Programming Language' translation
On May 5, 2011, at 2:31 PM, Jonathan Wakely wrote: > On 5 May 2011 18:52, Sergei Trofimovich wrote: >> ... >> I support your suspiction. Linking to that stuff is harmful. > > Thanks for checking them, Sergei. > > Now I'm convinced Bohdan Zograf is a link farmer and should be ignored. It sounds to me like the question "are you allowed to translate this" remains valid and open, even if this particular translator is not real. paul
Re: 'The GNU Compiler for the JavaTM Programming Language' translation
On 5 May 2011 18:52, Sergei Trofimovich wrote: > On Thu, 5 May 2011 16:28:34 +0100 > Jonathan Wakely wrote: > >> On 5 May 2011 16:08, Sergei Trofimovich wrote: >> >> And either Google Translate is very very good at Belarusian, or the >> >> pages this guy translates have just been piped through Google >> >> Translate. They're identical. >> > >> > And I'm afraid worthless. >> > >> > Can you show me a link? I'm kinda Belarusian native speaker. >> > blog format is a bit suspicious to maintain translation to the >> > er such an exotic language >> >> Send offlist to prevent a link from the gcc archive to the pages I >> consider suspicious. > > Yeah, both links are trashy. Text is grammatically incorrect (things like 'I > does' > are everywhere). > > I support your suspiction. Linking to that stuff is harmful. Thanks for checking them, Sergei. Now I'm convinced Bohdan Zograf is a link farmer and should be ignored.
Re: 'The GNU Compiler for the JavaTM Programming Language' translation
On Thu, 5 May 2011 16:28:34 +0100 Jonathan Wakely wrote: > On 5 May 2011 16:08, Sergei Trofimovich wrote: > >> And either Google Translate is very very good at Belarusian, or the > >> pages this guy translates have just been piped through Google > >> Translate. They're identical. > > > > And I'm afraid worthless. > > > > Can you show me a link? I'm kinda Belarusian native speaker. > > blog format is a bit suspicious to maintain translation to the > > er such an exotic language > > Send offlist to prevent a link from the gcc archive to the pages I > consider suspicious. Yeah, both links are trashy. Text is grammatically incorrect (things like 'I does' are everywhere). I support your suspiction. Linking to that stuff is harmful. -- Sergei signature.asc Description: PGP signature
Re: 'The GNU Compiler for the JavaTM Programming Language' translation
On 5 May 2011 16:08, Sergei Trofimovich wrote: >> And either Google Translate is very very good at Belarusian, or the >> pages this guy translates have just been piped through Google >> Translate. They're identical. > > And I'm afraid worthless. > > Can you show me a link? I'm kinda Belarusian native speaker. > blog format is a bit suspicious to maintain translation to the > er such an exotic language Send offlist to prevent a link from the gcc archive to the pages I consider suspicious.
Re: 'The GNU Compiler for the JavaTM Programming Language' translation
> And either Google Translate is very very good at Belarusian, or the > pages this guy translates have just been piped through Google > Translate. They're identical. And I'm afraid worthless. Can you show me a link? I'm kinda Belarusian native speaker. blog format is a bit suspicious to maintain translation to the er such an exotic language -- Sergei signature.asc Description: PGP signature
Re: 'The GNU Compiler for the JavaTM Programming Language' translation
On 5 May 2011 10:56, Jonathan Wakely wrote: > On 5 May 2011 09:38, Andrew Haley wrote: >> On 04/05/11 17:12, GM wrote: >> >>> I'm willing to translate publication located at http://gcc.gnu.org/java/ >>> to the Belorussian language (my mother tongue). What I'm asking for is >>> your written permission, so you don't mind after I'll post the >>> translation to my blog. The translation is intended only for web, no >>> print copies planned. >>> Visitors of your website, who come from Minsk (Belorussia) will be the >>> ones, who will read this blogpost, that's the only way to spread them, >>> no additional instruments we can use. Every translation we ever do does >>> not costs a penny for the webpage, which is translated. All we ask is to >>> link back in whatever way you feel confident about it. >> >> We're looking at the legal issues with respect to translation and >> copyright. We'll get back to you. >> >> Andrew. >> > > Where exactly is this blog that would contain the translation? > Searching the web does reveal some pages translated by this person (or > others using the same phone number sending the same email to lots of > mailing lists) but not on a single blog or website, instead hosted in > various generic web hosting places, webhostinghub dot com, > webhostinggeeks dot com, webhostingrating dot com. > > If I was in the business of creating link farms I would create dozens > of pages on different domains and get prominent websites such as open > source projects to provide links to them, then once I had those pages > in place I'd switch the content for whatever product I wanted to sell. > But maybe I'm just too suspicious and being unfair. > And either Google Translate is very very good at Belarusian, or the pages this guy translates have just been piped through Google Translate. They're identical. Maybe Google Translate is smart enough to realise there's a translation on the web already and uses it verbatim, but I don't think that's what's happening.
Re: 'The GNU Compiler for the JavaTM Programming Language' translation
On 5 May 2011 09:38, Andrew Haley wrote: > On 04/05/11 17:12, GM wrote: > >> I'm willing to translate publication located at http://gcc.gnu.org/java/ >> to the Belorussian language (my mother tongue). What I'm asking for is >> your written permission, so you don't mind after I'll post the >> translation to my blog. The translation is intended only for web, no >> print copies planned. >> Visitors of your website, who come from Minsk (Belorussia) will be the >> ones, who will read this blogpost, that's the only way to spread them, >> no additional instruments we can use. Every translation we ever do does >> not costs a penny for the webpage, which is translated. All we ask is to >> link back in whatever way you feel confident about it. > > We're looking at the legal issues with respect to translation and > copyright. We'll get back to you. > > Andrew. > Where exactly is this blog that would contain the translation? Searching the web does reveal some pages translated by this person (or others using the same phone number sending the same email to lots of mailing lists) but not on a single blog or website, instead hosted in various generic web hosting places, webhostinghub dot com, webhostinggeeks dot com, webhostingrating dot com. If I was in the business of creating link farms I would create dozens of pages on different domains and get prominent websites such as open source projects to provide links to them, then once I had those pages in place I'd switch the content for whatever product I wanted to sell. But maybe I'm just too suspicious and being unfair.
Re: 'The GNU Compiler for the JavaTM Programming Language' translation
On 04/05/11 17:12, GM wrote: > I'm willing to translate publication located at http://gcc.gnu.org/java/ > to the Belorussian language (my mother tongue). What I'm asking for is > your written permission, so you don't mind after I'll post the > translation to my blog. The translation is intended only for web, no > print copies planned. > Visitors of your website, who come from Minsk (Belorussia) will be the > ones, who will read this blogpost, that's the only way to spread them, > no additional instruments we can use. Every translation we ever do does > not costs a penny for the webpage, which is translated. All we ask is to > link back in whatever way you feel confident about it. We're looking at the legal issues with respect to translation and copyright. We'll get back to you. Andrew.
