Hans-Peter Nilsson wrote:
On Sun, 13 Mar 2005, Øyvind Harboe wrote:
Trampolines are strange things... :-)
- AFAICT, the cris target is saving the value of the
static chain register in the trampoline. How can that work
with recursive functions?
What's wrong with that?
Do I miss something fundam
On Sun, 13 Mar 2005, Øyvind Harboe wrote:
> Trampolines are strange things... :-)
> - AFAICT, the cris target is saving the value of the
> static chain register in the trampoline. How can that work
> with recursive functions?
What's wrong with that?
Do I miss something fundamental?
> Does t
Joern RENNECKE wrote:
You need to be able to set the value of a parameter over a widely
varying range, what makes you think you can pick two values that
will cover all cases, or 4 or 6 for that matter.
In order to allow to specify the exact size of the pool, you can provide
the
source of the lib
Robert Dewar wrote:
Joern RENNECKE wrote:
You need to be able to set the value of a parameter over a widely
varying range, what makes you think you can pick two values that
will cover all cases, or 4 or 6 for that matter.
It will likely cover most, but not all cases. With 12 values, you can cover
Joern RENNECKE wrote:
You need to be able to set the value of a parameter over a widely
varying range, what makes you think you can pick two values that
will cover all cases, or 4 or 6 for that matter.
Robert Dewar wrote:
Joern RENNECKE wrote:
Of course the user can change the size, by using a library with a
different size.
This is not an acceptable approach in a production environment,
where switching libraries can force revalidation and retesting.
This sounds more like a problem with your p
Joern RENNECKE wrote:
Of course the user can change the size, by using a library with a
different size.
This is not an acceptable approach in a production environment,
where switching libraries can force revalidation and retesting.
Clifford Wolf wrote:
Some applications have recursions which go into a depth of 1000 and more.
Some architectures have only a few k ram. Which "a size that works most of
the time" would you suggest?
It's ugly to have a static pool size. But it's intolerable to not allow the
user to change that
Hi,
On Thu, Mar 17, 2005 at 01:35:29PM +, Joern RENNECKE wrote:
> I.e. you could have libgcc provide one with a size that works most of the
> time
Some applications have recursions which go into a depth of 1000 and more.
Some architectures have only a few k ram. Which "a size that works most
Clifford Wolf wrote:
hmm.. what's about doing it gc-like. Instead of a stack there simply is a
'pool' of trampolines from which trampolines are allocated and a pointer to
the trampoline is pushed on the stack.
When the last trampoline from the pool is allocated, a 'garbage collector'
is runnin
hi,
On Wed, Mar 16, 2005 at 02:48:56PM -0500, Robert Dewar wrote:
> Yes, but that avoids the difficulty, that's obvious so far.
>
> The problem is to know exactly when to pop the stack, and that is
> not trivial (longjmp, exceptions, non local gotos).
hmm.. what's about doing it gc-like. Instead
Joern RENNECKE wrote:
In a single-threaded environment, you treat the trampoline pool as a
stack, and
when you allocate a new one, check first if there are any trampolines
left at the
top that have a static chain pointer that points into deallocated data
stack.
Yes, but that avoids the difficult
Clifford Wolf wrote:
Hi,
On Wed, Mar 16, 2005 at 01:50:32PM +, Joern RENNECKE wrote:
These can be provided in a separate module of the static libgcc, together
with allocation and deallocation of individual trampolines from the pool
(the latter has to be called from the epilogue of functions
On Wed, Mar 16, 2005 at 10:51:55AM -0400, Manuel Baez wrote:
> Please some moderator, remove me from this list, I'cant do it
Look at the "List-Unsubscribe" header.
Alternatively you could have tried going to the GCC web site and
clicking on "mailing lists", where you'll find a form to unsubscrib
ton; ?yvind Harboe; gcc@gcc.gnu.org
> Asunto: Re: Questions about trampolines
>
>
> Hi,
>
> On Wed, Mar 16, 2005 at 01:50:32PM +, Joern RENNECKE wrote:
> > These can be provided in a separate module of the static
> libgcc, together
> > with allocation and
Hi,
On Wed, Mar 16, 2005 at 01:50:32PM +, Joern RENNECKE wrote:
> These can be provided in a separate module of the static libgcc, together
> with allocation and deallocation of individual trampolines from the pool
> (the latter has to be called from the epilogue of functions that use
> initia
>> Any alternatives that would work for Harvard Architecture devices
such as the AVR would be welcome.
There are no alternatives that do not have an overhead in the case where
pointers to nested functions are *not* used, which seems unacceptable in
C. You could introduce some kind of pragma for a
Russell Shaw wrote:
=
How is a pointer to a nested function any different to a pointer to
an un-nested function? Why need trampolines?
Because you need the static link, do some research on the
use of static links if you don't understand that.
Michael N. Moran wrote:
Robert Dewar wrote:
Michael N. Moran wrote:
The AVR is a bit more extreme than the Harvard arch you're describing.
The AVR has completely separate address spaces for instructions and
data. Instruction data space cannot be accessed through a data space
pointer. There are sepa
On Tue, Mar 15, 2005 at 12:20:16PM +1100, Russell Shaw wrote:
> How is a pointer to a nested function any different to a pointer to
> an un-nested function? Why need trampolines?
Because you have to pass the context of that nested function somehow,
so that it can access variables in the outer func
E. Weddington wrote:
Michael N. Moran wrote:
Robert Dewar wrote:
But there must be a way to write stuff into the instruction data
space, or how would you load code? So you just have to setup an
auxiliary stack in code space.
The AVR is an embedded processor, and the instruction space is
is Flash *
Robert Dewar wrote:
> Waldek Hebisch wrote:
>
> > But there is no need to generate trampolines on the stack. Namely,
> > one can generate code in a separate area. In C this causes problems
> > with garbage collection, which IMHO can be solved, but requre alloca-like
> > tricks. On the other hand
Michael N. Moran wrote:
Robert Dewar wrote:
But there must be a way to write stuff into the instruction data
space, or how would you load code? So you just have to setup an
auxiliary stack in code space.
The AVR is an embedded processor, and the instruction space is
is Flash *not* RAM. We're not t
Robert Dewar wrote:
Michael N. Moran wrote:
The AVR is a bit more extreme than the Harvard arch you're describing.
The AVR has completely separate address spaces for instructions and
data. Instruction data space cannot be accessed through a data space
pointer. There are separate instructions for ac
On Mar 14, 2005, at 8:11 AM, Marc Espie wrote:
In article <[EMAIL PROTECTED]> you write:
Well as I said above, trampolines or an equivalent are currently
critically
needed by some front ends (and of course by anyone using the (very
useful IMO)
extension of nested functions in C).
This is your opi
Waldek Hebisch wrote:
But there is no need to generate trampolines on the stack. Namely,
one can generate code in a separate area. In C this causes problems
with garbage collection, which IMHO can be solved, but requre alloca-like
tricks. On the other hand trampolines in separate area may provide
Oyvind Harboe wrote:
> Trampolines are strange things... :-)
> - Lately e.g. the AMD CPU has added support for making it impossible
> to execute code on the stack. The town isn't big enough for
> both stack based trampolines and stack code execution protection.
> What happens now?
> - Do (th
On Mar 14, 2005, at 6:14 AM, Marc Espie wrote:
After enabling that patch, we recompiled the whole system, all of X,
and the
3000 packages of third party sources.
-ftrampolines was needed exactly 0 times.
We'll need it at least once that we know about for darwin. I don't
expect an impact from th
E. Weddington wrote:
Basically, trampolines don't work for the AVR because it is a Harvard
Architecture device.
Nearly all the processors on which trampolines are implemented are
Harvard architecture, it's really standard these days. That means that
cache flushing is a standard part of implementat
Robert Dewar wrote:
Øyvind Harboe wrote:
- Many backends do not support trampolines. Are trampolines
something that is ultimately being added to the backends?
We have not encountered any targets not supporting nested functions
in porting Ada to many different targets.
It's interesting that this
H. J. Lu wrote:
If we want to remove nested functions from glibc and keep code reuse,
I can try to provide a patch.
Just make sure that there are no instances of pointers to these
functions being taken. As long as there are no trampolines, there
seems to be no good argument for messing with the cod
Robert Dewar <[EMAIL PROTECTED]> writes:
| Marc Espie wrote:
| > In article <[EMAIL PROTECTED]> you write:
| >
| >>Well as I said above, trampolines or an equivalent are currently critically
| >>needed by some front ends (and of course by anyone using the (very useful
IMO)
| >>extension of nested
On Mon, Mar 14, 2005 at 02:57:36PM +0100, Andreas Schwab wrote:
> Marc Espie <[EMAIL PROTECTED]> writes:
>
> > On Mon, Mar 14, 2005 at 01:25:34PM +, Joseph S. Myers wrote:
> >> On Mon, 14 Mar 2005, Robert Dewar wrote:
> >>
> >> > I have certainly seen it used, but you may well be right that i
Marc Espie wrote:
I don't want to dive into the glibc mess, thanks god, but if the dynamic
linker is implemented like dynamic linkers I know, it means any binary
using a dynamic linker that uses trampolines will lose any kind of stack
protection on some badly designed architectures, like say, i386.
The thing I did for OpenBSD 3.7 is patch the gcc-3.3.x we use:
- On OpenBSD, by default, trampoline code generation is disabled in gcc
3.3.5. Code requiring trampolines will not compile without
-ftrampolines. The warning flag -Wtrampolines can be used to locate
Marc Espie <[EMAIL PROTECTED]> writes:
> On Mon, Mar 14, 2005 at 01:25:34PM +, Joseph S. Myers wrote:
>> On Mon, 14 Mar 2005, Robert Dewar wrote:
>>
>> > I have certainly seen it used, but you may well be right that it is
>> > seldom used. It is certainly reasonable to consider removing this
Hi,
On Mon, Mar 14, 2005 at 02:11:51PM +0100, Marc Espie wrote:
> In article <[EMAIL PROTECTED]> you write:
> >Well as I said above, trampolines or an equivalent are currently critically
> >needed by some front ends (and of course by anyone using the (very useful
> >IMO)
> >extension of nested fu
On Mon, Mar 14, 2005 at 01:25:34PM +, Joseph S. Myers wrote:
> On Mon, 14 Mar 2005, Robert Dewar wrote:
>
> > I have certainly seen it used, but you may well be right that it is
> > seldom used. It is certainly reasonable to consider removing this
> > extension from C and C++. Anyone using tha
Joseph S. Myers wrote:
Nested functions are used in the glibc dynamic linker. I'm not sure why,
and they may be inline nested functions whose addresses are never taken.
The extension is not present in GNU C++, only in GNU C.
Note that we do not need to discuss removing nested functions from C,
o
Giovanni Bajo wrote:
Last time this was discussed on gcc@, there was an agreement that since we
have to support trampolines for Ada & co.,
Right, but as per my last message, it is not true that we have to support
trampolines for Ada. Indeed trampolines are a pretty horrible implementation
mnechanis
[EMAIL PROTECTED] (Marc Espie) writes:
> In article <[EMAIL PROTECTED]> you write:
>>Well as I said above, trampolines or an equivalent are currently critically
>>needed by some front ends (and of course by anyone using the (very useful IMO)
>>extension of nested functions in C).
>
> This is your
On Mon, 14 Mar 2005, Robert Dewar wrote:
> I have certainly seen it used, but you may well be right that it is
> seldom used. It is certainly reasonable to consider removing this
> extension from C and C++. Anyone using that feature? Or know anyone
> who is.
Nested functions are used in the glibc
Robert Dewar <[EMAIL PROTECTED]> wrote:
>>> Well as I said above, trampolines or an equivalent are currently
critically
>>> needed by some front ends (and of course by anyone using the (very
useful
>>> IMO) extension of nested functions in C).
>>
>> This is your opinion, but I've yet to find an ac
Marc Espie wrote:
In article <[EMAIL PROTECTED]> you write:
Well as I said above, trampolines or an equivalent are currently critically
needed by some front ends (and of course by anyone using the (very useful IMO)
extension of nested functions in C).
This is your opinion, but I've yet to find an
In article <[EMAIL PROTECTED]> you write:
>Well as I said above, trampolines or an equivalent are currently critically
>needed by some front ends (and of course by anyone using the (very useful IMO)
>extension of nested functions in C).
This is your opinion, but I've yet to find an actual piece of
Øyvind Harboe wrote:
My worry is that the trampoline is only built once, but modified
multiple times. How does the CRIS target know that the saved static
chain register does not get overwritten by recursion?
This sounds wrong to me
I believe e.g. Windows XP service pack 2 has this protection enable
On Mon, Mar 14, 2005 at 08:34:32AM +0100, ?yvind Harboe wrote:
> > > - Lately e.g. the AMD CPU has added support for making it impossible
> > > to execute code on the stack. The town isn't big enough for
> > > both stack based trampolines and stack code execution protection.
> > > What happe
> Zack says in his post that the Ada and Pascal nested functions do not
> use trampolines.
>
> http://gcc.gnu.org/ml/gcc/2005-03/msg00642.html
You misread. Pointers to nested functions always require trampolines.
> The main advantage I see of having nested functions & trampolines in C
> is that
> > - AFAICT, the cris target is saving the value of the
> > static chain register in the trampoline. How can that work
> > with recursive functions? Does the cris target PASS or FAIL
> > gcc.dg/trampoline-1.c?
>
> It should work fine, because the trampoline is supposed to be
> built on the
Øyvind Harboe wrote:
Trampolines are strange things... :-)
- Are nested functions part of the C standard or a GCC extension?
I believe the answer is a GCC extension. I have seen evidence,
but no proof to this effect.
They are of course a gcc extension
- AFAICT, the cris target is saving the val
Øyvind Harboe <[EMAIL PROTECTED]> writes:
> - AFAICT, the cris target is saving the value of the
> static chain register in the trampoline. How can that work
> with recursive functions?
Every stack frame has its own trampoline.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE
Ãyvind Harboe <[EMAIL PROTECTED]> writes:
> - Many backends do not support trampolines. Are trampolines
> something that is ultimately being added to the backends?
As and if the port maintainers care, I think.
> - Do (theoretical?) alternatives to trampolines exist?
> I.e. something that do
> - Are trampolines used for anything else but nested functions
> in C? I believe they are used by Ada.
<...>
> My personal uninformed opinion is that trampolines cause more trouble
> than they are worth.
Ada, Fortran and Pascal all require nested functions.
Paul
On Sun, Mar 13, 2005 at 09:24:19PM +0100, Øyvind Harboe wrote:
> Trampolines are strange things... :-)
>
> - Are nested functions part of the C standard or a GCC extension?
> I believe the answer is a GCC extension. I have seen evidence,
> but no proof to this effect.
That is right.
> - AFAI
Trampolines are strange things... :-)
- Are nested functions part of the C standard or a GCC extension?
I believe the answer is a GCC extension. I have seen evidence,
but no proof to this effect.
- AFAICT, the cris target is saving the value of the
static chain register in the trampoline. Ho
55 matches
Mail list logo
