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
Sam Lauber wrote:
The gccinstall info says that `make uninstall' would open
a can of worms. I don't get it. Why?
I suspect because it's tested so infrequently and may not remove the complete set of
files (or files belonging to other packages installed under the same prefix). Most
people would b
There is decent documentation of the dg-* directives in comments at
the top of $prefix/share/dejagnu/dg.exp, where $prefix refers to your
dejagnu installation. I do agree with Joseph that this ought to be in
the dejagnu manual.
The DejaGnu manual needs a lot of work (which I intend to tackle in er
On Mon, Mar 14, 2005 at 04:49:41PM -0800, Eric Christopher wrote:
>
> > > Now, I wouldn't object to hacking GCC to avoid cross-jumping calls to
> > > abort. It's just that I don't think that the common GNU use of abort
> > > serves the users.
> > Agreed. And as someone suggested, rather than tre
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 *
> > Now, I wouldn't object to hacking GCC to avoid cross-jumping calls to
> > abort. It's just that I don't think that the common GNU use of abort
> > serves the users.
> Agreed. And as someone suggested, rather than treating abort
> specially within GCC, I think we'd be better off with a functi
On Mon, 2005-03-14 at 16:17 -0800, Joe Buck wrote:
> On Mon, Mar 14, 2005 at 06:44:16PM -0500, Richard Stallman wrote:
> > After some 20 years of developing popular free software, I have
> > somewhat of an idea what users are likely to do.
>
> Many of us have developed software for a similar perio
Joe Buck wrote:
But it seems to me that the practice of using abort() as it is now used
in many GNU programs is a holdover from 20 years ago when the engineering
tradeoffs were different. We can afford to tell the user more.
In addition, crossjumping calls to abort does more than just save space;
On Mon, Mar 14, 2005 at 06:44:16PM -0500, Richard Stallman wrote:
> After some 20 years of developing popular free software, I have
> somewhat of an idea what users are likely to do.
Many of us have developed software for a similar period of time,
and yet feel differently.
> I don't use
> fancy_a
On Mon, Mar 14, 2005 at 06:44:09PM -0500, Richard Stallman wrote:
> 'abort: core dumped' is not a good user experience. If code is being
> shipped with naked aborts in it, that is where the problem lies.
>
> You're entitled to your opinion, but such a conclusion requires much
> stronger b
Most people don't do debugging. For some reason you appear to think
that every free software user is also a free software debuggers.
After some 20 years of developing popular free software, I have
somewhat of an idea what users are likely to do. I don't use
fancy_abort functions because
The __FILE__ strings will be combined, so you get a most one of it for
each object file.
You're right about that. So the increase in size due to fancy_abort
will be somewhat less than I previously said. However, it will still
be an increase in size, compared with using abort and not
cros
'abort: core dumped' is not a good user experience. If code is being
shipped with naked aborts in it, that is where the problem lies.
You're entitled to your opinion, but such a conclusion requires much
stronger basis than this.
If
cross jumping makes debugging harder, tough --
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
On Mar 14, 2005, at 10:30 AM, Joe Buck wrote:
Steven Bosscher <[EMAIL PROTECTED]> wrote:
system.h:#define abort() fancy_abort (__FILE__, __LINE__,
__FUNCTION__)
I agree that this is the best technical solution, even if cross-jumping
were not an issue.
This invokes undefined behavior in a pro
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
Distributions would have to triple the number of CDs shipped. Most
users don't know how to run a debugger. This means that there is no
debug information available until a developer tries to duplicate the
problem report. With or without cross-jumping, when the developer
gets a
Steven Bosscher <[EMAIL PROTECTED]> wrote:
system.h:#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
I agree that this is the best technical solution, even if cross-jumping
were not an issue.
Also:
On Monday 14 March 2005 04:00, Richard Stallman wrote:
> > But you recommend a
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
On Sat, Mar 12, 2005 at 11:55:03PM -0600, Aaron W. LaFramboise wrote:
> Is there a reason why non-bootstrap build status reports are not
> archived? For example, for the many targets that are only used in cross
> configurations, it would be nice to see if they are working.
First off, let me apolo
> From: James E Wilson <[EMAIL PROTECTED]>
> Date: Fri, 11 Mar 2005 17:52:03 -0800
> On Fri, 2005-03-11 at 08:12, Hans-Peter Nilsson wrote:
> > I don't really understand what you mean: if a thing is called
> > "foo" in the source, then -fglobalize-symbol=foo would work.
>
> My main concern is tha
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
On Sat, 12 Mar 2005 03:02:20 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> said:
> David Carlton <[EMAIL PROTECTED]> writes:
>> On Thu, 10 Mar 2005 15:54:03 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]>
>> said:
>>> Vincent Lefevre <[EMAIL PROTECTED]> writes:
On 2005-03-10 01:01:18 +0100, Gabriel
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
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sun, 2005-03-13 at 15:26 +0100, Gabriel Dos Reis wrote:
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| >
| > | On 2005-03-12 02:59:46 +0100, Gabriel Dos Reis wrote:
| > | > You probably noticed that in the polynomial expansion, you are using
| > |
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
The gccinstall info says that `make uninstall' would open
a can of worms. I don't get it. Why?
Samuel Lauber
--
_
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.
Powere
Hello,
I assume you want to use individual assignments, is that correct?
I have attached the employer disclaimer. In addition, I have attached a
questionnaire. This questionnaire includes instructions for its
completion. Upon receipt of the questionnaire, the FSF will review the
answers, and if
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
Richard Stallman wrote:
Otherwise, we need to consider the merits of disabling an optimization
to make debugging easier.
Optimizing calls to `abort' doesn't offer much benefit, so I think in
this particular case it is worth disabling cross-jumping.
This is a difficult choice to make
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
On Mon, 2005-03-14 at 03:00, Richard Stallman wrote:
> This is a difficult choice to make, but at
> -O2, I'd prefer that we optimize, and suggest other debugging techniques
> intead of relying on the line numbers of abort calls.
>
> The sole purpose of optimization is to satisfy us
Ø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 Monday 14 March 2005 04:00, Richard Stallman wrote:
> Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> system.h:#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
>
> where fancy_abort is a, well, fancy abort that prints some more
> information about what happened, and wher
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
Richard Stallman <[EMAIL PROTECTED]> writes:
> Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> system.h:#define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
>
> where fancy_abort is a, well, fancy abort that prints some more
> information about what happened, and where. IMVHO
> 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
55 matches
Mail list logo
