|
From: Tom H. <th...@cy...> - 2004-06-27 11:32:14
|
In message <71c...@lo...>
Tom Hughes <th...@cy...> wrote:
> In message <4da...@ma...>
> Joseph Turian <tu...@gm...> wrote:
>
> > I wanted to pass on a comment from the Gentoo bug report:
> > "On another note it would be nice to get all of the trampolines
> > resolved in valgrind as well."
> > (http://bugs.gentoo.org/show_bug.cgi?id=54068#c5)
> >
> > Not sure what is meant by this, but maybe you do.
>
> I have no idea what it means... Perhaps you could find out?
>
> The only thing I can think they're talking about is the issue with
> nested functions in gcc, which cause trampolines to be built on the
> stack that valgrind can't handle.
I've now heard from the person who wrote that and apparently what they
were talking about is the fact that several routines in valgrind use
nested functions themselves, which causes gcc to mark those object as
needing an executable stack which in turn stops things like NX support
from kicking in.
Does anybody have any particular objections to removing the use of
nested functions in valgrind? I haven't looked at it in any detail
yet and I know that at least some of them make use of stack variables
from the parent function which makes removing them non-trivial but
it could be done.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2004-06-27 12:14:12
|
On Sunday 27 June 2004 12:39, Nicholas Nethercote wrote: > On Sun, 27 Jun 2004, Tom Hughes wrote: > > Does anybody have any particular objections to removing the use of > > nested functions in valgrind? I haven't looked at it in any detail > > yet and I know that at least some of them make use of stack variables > > from the parent function which makes removing them non-trivial but > > it could be done. [...] > > Another advantage of removing the nested functions is that the practice is > one of the things that prevents Valgrind from being compiled with the > Intel C compiler. It's the only thing, I think, that prevents building with Icc. At some point in the past I did exactly this nested fn removal, and the result works with Icc. It's an hour's work or so, not a big deal. It'll make you a Hero(tm) with the Icc people, who have asked more than once to make valgrind icc-compilable. Probably a good thing to do. Another reason is Icc uses a completely different C/C++ front end from gcc/g++ and so produces a whole different set of warnings. Ideally V should compile cleanly with both compilers. J |
|
From: Tom H. <th...@cy...> - 2004-06-27 17:39:06
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> It's the only thing, I think, that prevents building with Icc. At some
> point in the past I did exactly this nested fn removal, and the result
> works with Icc. It's an hour's work or so, not a big deal. It'll
> make you a Hero(tm) with the Icc people, who have asked more than once
> to make valgrind icc-compilable.
I've done the deed. Some things I fixed using static data and some
by adding extra parameters that are passed to callback routines.
I also added a line to each of the assembly source files to declare
them as not needing an executable stack otherwise valgrind and one of
the skins still wind up being marked as needed an executable stack.
> Probably a good thing to do. Another reason is Icc uses a completely
> different C/C++ front end from gcc/g++ and so produces a whole
> different set of warnings. Ideally V should compile cleanly with
> both compilers.
Don't we use lots of other gcc extensions though, like attributes and
inline assembler.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-27 17:49:24
|
On Sun, 27 Jun 2004, Tom Hughes wrote: > Don't we use lots of other gcc extensions though, like attributes and > inline assembler. Apparently icc supports a lot of the extensions, precisely for gcc compatibility. N |
|
From: Julian S. <js...@ac...> - 2004-06-27 17:50:00
|
> I've done the deed. Some things I fixed using static data and some > by adding extra parameters that are passed to callback routines. Cool! > > Probably a good thing to do. Another reason is Icc uses a completely > > different C/C++ front end from gcc/g++ and so produces a whole > > different set of warnings. Ideally V should compile cleanly with > > both compilers. > > Don't we use lots of other gcc extensions though, like attributes and > inline assembler. Yes we do, but icc can manage lots of the gcc extensions. Nested fns is one of the few extensions it can't do. J |
|
From: Bryan O'S. <bo...@se...> - 2004-06-28 04:10:23
|
On Sun, 2004-06-27 at 13:51 +0100, Julian Seward wrote: > It's the only thing, I think, that prevents building with Icc. And with the PathScale compiler, which has the same no-nested-functions restriction as icc. <b -- Bryan O'Sullivan <bo...@se...> |
|
From: Nicholas N. <nj...@ca...> - 2004-06-27 11:39:15
|
On Sun, 27 Jun 2004, Tom Hughes wrote:
> Does anybody have any particular objections to removing the use of
> nested functions in valgrind? I haven't looked at it in any detail
> yet and I know that at least some of them make use of stack variables
> from the parent function which makes removing them non-trivial but
> it could be done.
I don't mind. The usual hack is to use a global variable, eg:
int foo(int x)
{
int nest(void)
{
... something with x ...
}
...
}
becomes
int x_for_nest_in_foo;
int foo(int x)
{
x_for_nest_in_foo = x;
int nest(void)
{
... something with x_for_nest_in_foo ...
}
...
}
I think there are a couple of examples like this already. I like to use
horrible long names for the global variables that make it extremely clear
why they're there.
Another advantage of removing the nested functions is that the practice is
one of the things that prevents Valgrind from being compiled with the
Intel C compiler.
N
|
|
From: Jeremy F. <je...@go...> - 2004-06-27 19:54:21
|
On Sun, 2004-06-27 at 12:32 +0100, Tom Hughes wrote: > I've now heard from the person who wrote that and apparently what they > were talking about is the fact that several routines in valgrind use > nested functions themselves, which causes gcc to mark those object as > needing an executable stack which in turn stops things like NX support > from kicking in. > > Does anybody have any particular objections to removing the use of > nested functions in valgrind? I haven't looked at it in any detail > yet and I know that at least some of them make use of stack variables > from the parent function which makes removing them non-trivial but > it could be done. I'd object. It makes the code a lot cleaner in a lot of places, and in general I think nested functions are a good idea. NX is basically useless, particularly for Valgrind, so I don't think there's any reason to inconvenience ourselves over it. J |