Re: Questions about trampolines

[Eric Botcazou]

> 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 they will see more testing. I think it would be really tough
> for, say Ada, to rely on features in the backend that are not used at
> all by C/C++.

That's already the case for other features, although these are primarily 
middle-end features.

-- 
Eric Botcazou

Re: Merging calls to `abort'

[Andreas Schwab]

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 any moderately
> large piece of software that uses abort should consider using this
> kind of construct, or use assert.
>
> Look at the irony of this recommendation.
>
> This technique will work, but it is rather wasteful.  Each abort call,
> if handled this way, requires two string constants that are redundant

The __FILE__ strings will be combined, so you get a most one of it for
each object file.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Questions about trampolines

[Clifford Wolf]

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 happens now? 
> > 
> > Usually it is possible to disable this stack protection. If it is not
> > possible, then that's a very serious limitation.

But OpenBSD either ignores it or gcc doesn't set the stack executable on
OpenBSD.

At least my trampoline example (http://www.clifford.at/cfun/gccfeat/gccfeat01.c)
segfaults on OpenBSD when trying to execute the trampoline code..

> I believe e.g. Windows XP service pack 2 has this protection enabled. 

I don't think so. Afaik even an Opteron (and the compatibles) only have an
extra "execute" page permission when running 64 bit programs. It doesn't
change anything for 32 bit binaries.

There is a pentium CPU register which contains the highest executeabe
address. But using it "the right way" would require rebuilding all apps so
all executeable adrresses are in the lower half of the virtual memory and
all data in the upper half. This couldn't be done with a simple change in
the operating system (unless there really aren't any executeable
addresses above the stack frame - then it could be done for the stack but
not for all other data segments).

yours,
 - clifford

-- 
| Clifford Wolf /-=[ www.clifford.at ]==[ Tel: +43-699-10063494 ]=-\
|--/ www.cngw.org - www.ccc.de =[ Fax: +43-2235-42788-4 ]=-|
|-=[ EDEN Creations -- www.edenevents.at ]==[ IRC: www.freenode.net ]=-|
\==[ www.rocklinux.org ]===[ www.rocklinux.net ]===[ www.linbit.com ]==/
 
When your hammer is C++, everything begins to look like a thumb.
 


pgptMvLNXPaWo.pgp
Description: PGP signature

Re: Merging calls to `abort'

[Steven Bosscher]

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 where.  IMVHO any moderately
> large piece of software that uses abort should consider using this
> kind of construct, or use assert.
>
> Look at the irony of this recommendation.
>
> This technique will work, but it is rather wasteful.  Each abort call,
> if handled this way, requires two string constants that are redundant
> with the program's debugging info.

It is not as bad as you are trying to project it.  All duplicate
strings are merged.  And you should be happy with the function name
and line number, it gives the developers the exact location of where
a problem occured.  Wasn't that your original complaint, that you
could not tell the line number of an abort?

> It also requires the user to 
> change the program, which is a further inconvenience.

The only change it requires is a whopping *one* extra line in some
header that is included everywhere.  Oh dear, what a terrible thing
to ask of the developer, what a terrible inconvenience for much more
accurate debugging information!

> What's the point of cross-jumping? ÂIt saves a certain amount of
> space; it has no other benefit. ÂAll else being equal, there's no
> reason not to do it. ÂBut cross-jumping abort calls interferes with
> debugging. ÂThat's a good reason not to do it.

Most people don't do debugging.  For some reason you appear to think
that every free software user is also a free software debuggers.
Well, newsflash, that is not the case.  The majority of free software
users have never even looked at the source code.
If users are going to report bugs, then for the developers it is very
useful to know the name of the function and the line where the failure
occured.  The only way for a user to know this information, is when
the crashing program reports it.  So you *need* a fancy_abort like
replacement of abort (e.g. gcc's fancy_abort, or assert) if you want 
your users to be able to produce accurate bug reports.

> But you recommend a different solution to this problem: changing all
> the abort calls so that (1) they can't be cross-jumped and (2) they  
> use even more space.  If everyone follows your recommendation, not 
> only will no abort calls ever be cross jumped, but the net result will
> be to make the compiled program even bigger than it would have been.

You don't have to change any abort calls in the source code, you just
replace the definition of abort.  You are greatly exaggerating the
increase in space my recommendation would cause.  And you complain
that no abort calls can ever be crossjumped, but you are saying that
should not ever happen anyway, so your point is moot.

> This makes no sense.

Your silly overstatement of the burden on the user to change the
program, and the point that crossjumping is a useless optimization,
are the only things that makes no sense.

> So please let's get rid of this optimization.  Those who want to use a
> fancy_abort function will still be able to do so, but this change will
> be an improvement for the rest.

With your suggestion, "those who want to use a fancy_abort" are the
ones who pay.  In case you had not noticed, this would actually
hurt a number of large free software projects, including GCC itself.

Gr.
Steven

Re: Questions about trampolines

[Robert Dewar]

Ø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 enabled.
There is no problem in building trampolines in this environment as far
as I know.
Zack says in his post that the Ada and Pascal nested functions do not
use trampolines.
He said nothing of the kind. Please reread. He said that for many
uses, they were not used, but when 'Access is taken in Ada (or in
fact for all task types, which use this mechanism internally) or
when a procedure is passed as a parameter in Pascal, then trampolines
are most certainly used.

I was surprised to see trampolines in GCC code. To me they are something
inbetween traditional C and C++ objects.
Not sure what this means
The main advantage I see of having nested functions & trampolines in C
is that they will see more testing. I think it would be really tough
for, say Ada, to rely on features in the backend that are not used at
all by C/C++.
It has worked fine for 12 years, and seems to continue to work fine!

Re: Merging calls to `abort'

[Richard Earnshaw]

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 users more.  If the
> result of this optimization in this particular case is that users are
> dissatisfied, GCC should adapt to the users, not vice versa.
> To say to the users, "GCC doesn't do what you want if you write X,
> so write Y instead", is distinctly inferior to changing GCC so it
> does what you want if you write X.

I disagree with the conclusions you reach from this statement. 
Optimization is really about minimizing some cost metric.  If a user has
asked for gcc to use 'smallest code size' (-Os), for example, then they
aren't going to be satisfied if GCC has not done this on the grounds
that debugging might become a little harder.  The same principle applies
equally to other trade-offs when it comes to -O2 and debugging.  There
are times when an optimization can make debugging so difficult that we
only enable it at -O3, but in the end the user still has control.  Your
suggestion would remove that control.

As things currently stand in GCC, if you really want accurate debugging
you pretty much have to compile -O0.  This is unfortunate, because gcc's
-O0 code is really very poor quality.  I personally think it would be
very nice if gcc had a -Og type option which gave reasonable code with
minimal loss of debugging accuracy.  For example, it would do as much
optimization as possible (cse, combine etc), within a statement, but
would not optimize across statement boundaries.  With such a mode, the
machine state at the end of each statement would exactly represent the
abstract model described by the program at that point.

R.

Re: Questions about trampolines

[Marc Espie]

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 code in a
real project that uses that extension.

On the other hand, non-executable stack is a feature used in the real
world. Quite in common use actually...

Think about that.

Re: Questions about trampolines

[Robert Dewar]

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 actual piece of code in a
real project that uses that extension.
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.
On the other hand, non-executable stack is a feature used in the real
world. Quite in common use actually...
Think about that.
Well you only disable the execution of the stack if you use trampolines
you don't need to do it unconditionally. I agree that with C code, it is
desirable to protect the stack in this way, since it is so easy in C to
create code that has buffer overruns. This is much less true in Ada so
that's less of a consideration.
I think it would be reasonable to contemplate removing trampolines.
Never mind the stack protection issue, the fact is that cache management
has made trampolines horribly expensive on many new architectures.
So that would mean eliminating the extension from C, and redoing function
pointers in Ada (and Pascal, and Fortran??) to use a double pointer, which
would be far more efficient for many (but not all) programs.

Re: Questions about trampolines

[Giovanni Bajo]

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 actual piece of code in a
>> real project that uses that extension.
>
> 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.

Last time this was discussed on gcc@, there was an agreement that since we
have to support trampolines for Ada & co., we can as well keep the extension
in C, which allows easier testcases, reductions (as most developers do not
understand Ada) and let the feature be tested even within gcc.dg.
-- 
Giovanni Bajo

Re: Questions about trampolines

[Joseph S. Myers]

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 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.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Questions about trampolines

[Andreas Schwab]

[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 opinion, but I've yet to find an actual piece of code in a
> real project that uses that extension.

glibc once did, but that has been fixed long ago.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Questions about trampolines

[Robert Dewar]

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
mnechanism that would never be chosen for an Ada compiler written from
scratch (too inefficient).

Re: Questions about trampolines

[Robert Dewar]

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,
only taking pointers to nested functions. We certainly want to retain
the static chain mechanism. That *is* fundamental to languages supporting
nested procedures.
So more accurately the question that should be asked is whether anyone
is using nested functions in C *and* taking pointers to them.

Re: Questions about trampolines

[Marc Espie]

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 that feature? Or know anyone
> > who is.

> 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.

Well, Andreas Schwab seems to think this is no longer the case.

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...

Re: Questions about trampolines

[Clifford Wolf]

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 functions in C).
> 
> This is your opinion, but I've yet to find an actual piece of code in a
> real project that uses that extension.

http://svn.clifford.at/spl/trunk/modules/mod_xml.c

.. much easier this way as by passing everything with the userdata pointer.

I've also seen already APIs with callbacks which do not support userdata
pointers. While I am agree that those APIs are broken it is still a good
feeling to know that it is possible to work around this issues using nested
functions...

yours,
 - clifford

-- 
bash -c "gcc -o mysdldemo -Wall -O2 -lSDL -lm -pthread -x c <( echo -e '
#include \n#include \nint main(){SDL_Surface*s;SDL_Event
e;int x,y,n;SDL_Init(SDL_INIT_VIDEO);s=SDL_SetVideoMode(640,480,32,0);for(x=0;
x<640;x++)for(y=0;y<480;y++){float _Complex z=0, c=((x-400)/200.0) + ((y-240)/
200.0)*1.0fi;for(n=1;n<64;n++){z=z*z+c;if(cabsf(z)>2){((Uint32*)s->pixels)[x+y
*640]=n<<3;n=99;}}}SDL_UpdateRect(s,0,0,s->w,s->h);do SDL_WaitEvent(&e); while
(e.type!=SDL_QUIT&&e.type!=SDL_KEYDOWN);SDL_Quit();return 0;}' ); ./mysdldemo"
 
Programming graphics in X is like finding sqrt(pi) using Roman numerals.
 


pgpxjVrWkAgnJ.pgp
Description: PGP signature

Re: Questions about trampolines

[Andreas Schwab]

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
>> > extension from C and C++. Anyone using that feature? Or know anyone
>> > who is.
>
>> 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.
>
> Well, Andreas Schwab seems to think this is no longer the case.

Actually glibc still uses nested functions, but does not take the address
of those being left.  The only reason that nested functions are still
being used is that it allows for easier code reuse.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Merging calls to `abort'

[Nathan Sidwell]

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, 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 users more.  If the
'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.  If
cross jumping makes debugging harder, tough -- debugging is hard,
debugging optimized programs is harder.  Using abort, rather than assert
is not sensible.
I wonder what the size tradeoff is between using non-cross jumped aborts
and using asserts ...
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: Questions about trampolines

[Marc Espie]

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
 trampoline instances if trampoline generation is re-enabled.


that way, you still have trampolines available in C if you need them, but you
don't risk compiling dangerous code that disables executable stack protection
by mistake.

It's probably quite trivial to write a similar patch for gcc-current,
assuming you guys think it's the right design decision.

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.

Re: Questions about trampolines

[Robert Dewar]

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...
Again, be careful to distinguish between use of nested functions (which does
not require trampolines), and taking pointers to such functions (which does
require trampolines). Normal use of nested functions without taking pointers
is entirely compatible with protecting the stack.
I would say that the use of trampolines should be pretty severely deprecated
in C, and I would think that as an intermediate stage, that code that takes
the address of a nested function should get a big warning that this may be
incompatible with protected stacks, and may be inefficient.

[gnu.org #222786] GCC Testsuite Tests Exclude List Contribution to FSF

[Ted Teah via RT]

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 everything is proper we will mail an assignment to the
person.

All the best,
Ted Teah
Please email the following information to [EMAIL PROTECTED], and we
will send you the assignment form for your past and future changes.
Please use your full name as the subject line of the message.


[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your snail address here.]





[Which files have you changed so far, and which new files have you written
so far?]
ïIf you are employed to do programming (even at a university), or have
made an agreement with your employer or school saying it owns programs
you write, then you and we need a signed piece of paper from your
employer disclaiming rights to the program.

Here is a disclaimer your employer can sign to cover your future
changes to GNU software, as well as your past changes.

The disclaimer should be signed by a vice president or general manager
of the company.  If you can't get at them, anyone else authorized to
issue licenses for software produced there will do.

Much of this disclaimer consists of a description of which kinds of
work it applies to.  This description is just a suggestion--your
employer can replace it with any description that says clearly which
kinds of work they want to disclaim and which kinds they don't.
Paragraph (b) is optional; they can delete it if they wish.

If your employer says they do have an intellectual property claim that
could conflict with the use of the program, then please put us in
touch with a suitable representative of the company, so that we can
negotiate what to do about it.  Send a note about the issue to the
company representative and to [EMAIL PROTECTED]

IMPORTANT: When you talk to your employer, *no matter what
instructions they have given you*, don't fail to show them the sample
disclaimer below, or a disclaimer with the details filled in for your
specific case.  Companies are usually willing to sign a disclaimer
without any fuss.  If you make your request less specific, you may
cloud the issue and cause a long and unnecessary delay.

Please keep a copy of the employer's signed disclaimer, and snail the
original to us at

Attn: Disclaimer Clerk
Free Software Foundation
59 Temple Place, Suite 330
Boston, MA  02111-1307
USA



   EMPLOYER DISCLAIMER OF RIGHTS

   We agree that software and other authored works of the 'Released
Category' (defined below), made by our employee/consultant,
___, prior to the date of this document, and for
_ years thereafter, are freely assignable by said
employee/consultant to Free Software Foundation (FSF) for distribution
and sharing under its free software policies.  We disclaim any status
as the author or owner of such works.

   The Released Category comprises

(a) changes and enhancements to software already (as of the time such
change or enhancement is made) freely circulating under stated terms
permitting public redistribution, whether in the public domain, or
under the FSF's GNU General Public License, or under the FSF's GNU
Lesser General Public License (a.k.a. the GNU Library General Public
License), or under other such terms; and

(b) operating system components for operating systems providing
substantially the same functionality as portions of UNIX, BSD,
Microsoft Windows, or other popular operating systems.

The Released Category excludes __ [if 'none',
please so state; thank you--FSF].

   We affirm that we will do nothing in the future to undermine this
release.  If we have or acquire hereafter any patent or interface
copyright or other intellectual property interest dominating the
works, or the programs to which these works constitute changes and
enhancements, or use of those programs, then the Free Software
Foundation and the general public will be permanently and irrevocably
licensed to use, in these works and in the programs they enhance,
without royalty or limitation, the subject matter of the dominating
interest.

   We make no warranty as to the quality of the material or as to
the presence or absence of rights therein of any other party, and we
do not purport to disclaim, release or grant any rights other than our
own.

   Given as a sealed instrument this ___ day of __

`make uninstall' and GCC

[Sam Lauber]

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.

Powered by Outblaze

Re: Questions about trampolines

[H. J. Lu]

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 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 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.
> >
> > Well, Andreas Schwab seems to think this is no longer the case.
> 
> Actually glibc still uses nested functions, but does not take the address
> of those being left.  The only reason that nested functions are still
> being used is that it allows for easier code reuse.
> 

If we want to remove nested functions from glibc and keep code reuse,
I can try to provide a patch.


H.J.

Re: Dear adventurers of math! (was Re: __builtin_cpow((0,0),(0,0)))

[Gabriel Dos Reis]

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
| > | > an integer power -- which everybody agrees on yield 1 at the limit.
| > | > 
| > | > I'm tlaking about 0^0, when you look at the limit of function x^y
| > | > -- which is closer to cpow() tgan powi().  Did you miss that?
| > | 
| > | When one uses the power notation in mathematics, one (almost) never
| > | says when the context is a function R x R -> R or R x Z -> R or
| > | whatever.
| > 
| > That is (almost) absolutely false.
| > 
| > | The problem is the same in ISO C99 (and probably other
| > | languages),
| > 
| > Other languages do make the distinction.  That C99 did not have the
| > syntax for that is a defect rather than virtue. Examples have been
| > provided, but I guess you prefer to ignore them.
| > 
| > -- Gaby
| 
| As much fun as it is to get random messages on the gcc mailing list

not as much as getting one from you.

The issue has to do with whatsemantics GCC should implement.

-- Gaby

Re: Questions about trampolines

[Gabriel Dos Reis]

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 functions in C).
| > This is your opinion, but I've yet to find an actual piece of code
| > in a
| > real project that uses that extension.
| 
| 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.

GNU C++ does not have nested functions.  Standard C++ local classes
provide good support, IMHO.

-- Gaby

Re: Questions about trampolines

[Robert Dewar]

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 code here.

Re: __builtin_cpow((0,0),(0,0))

[David Carlton]

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 Dos Reis wrote:

> The asseryion that 0^0 is mathematically undefined is not a
> bogus reason. It is a fact.

 I disagree. One can mathematically define 0^0 as 1. One often
 does this.

>>> what you do is to set a local convention regardless of all
>>> mathematical absurdities you run into.

>> No, you follow the convention that all mathematicians that I know
>> of follow, because it's generally recognized as the most useful
>> one.

> Please given references -- not just unnamed mathematicians you claim
> to know.

I don't have my math books with me; sorry.  As far as "claim to know",
that's a little bit over the top; I suppose you could start at
 and poke around,
if you're seriously worried that I don't in fact know any
mathematicians.

>> Maybe there are mathematical subcultures in which a different
>> convention (or no convention) is followed; I haven't spent time in
>> such cultures.  But if it's a "local convention", then it's one for
>> a very large value of "local".

> Please consider the limit of x^y when you have both x and y go to
> zero.

There isn't one, of course.  That doesn't prevent people from deciding
which convention is most useful.  After all, in general,
exponentiation isn't uniquely defined almost anywhere: for example, if
you fix y = 1/2, then you're looking at the square root function, and
numbers have two square roots.  So I can "prove" that 4^(1/2) isn't
well defined by taking the limit of x^(1/2) as x goes in a circle
around the origin in the complex plane, starting and ending at 4, and
getting the answer of 2 at the start and -2 at the end.  But people
pick a convention nonetheless, and say that 4^(1/2) = 2.

I'll admit that my background might be somewhat skewed, since I've
spent most of my time in areas that are relatively strongly influenced
by algebra, and there x^0 = 1 for all x is the only definition that
makes sense (because of polynomials, power series, etc.).  I would
think I'd spent enough time around analysts (for some values of
"analysts": complex analysts likely, real analysts probably, numerical
analysts very little) to know if they had another opinion on the
matter, but I'm less confident there: that's why I talked about other
mathematical subcultures.  Maybe the group that produced LIA-2 is such
a subculture.

David Carlton
[EMAIL PROTECTED]

Re: Questions about trampolines

[E. Weddington]

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 subject was brought up.
There is a project called AVR-Ada, to add Ada to the AVR target:

And there was recent discussion on the avr-gcc-list about the role of 
nested functions which led to discussion about trampolines and Ada for 
the AVR:


Basically, trampolines don't work for the AVR because it is a Harvard 
Architecture device.

This will also affect other similar devices, for example, the new MaxQ 
target support that is going into GCC. IIRC, It's also a Harvard 
Architecture device.


- Do (theoretical?) alternatives to trampolines exist? I.e. something
  that does not generate code runtime.

Yes, you could have double length pointers for function pointers (pointer
to code + static link). This is the more conventional implementation, but
it introduces an overhead when not using nested functions. This overhead
is more than acceptable in Ada, where it would be very nice to get rid
of trampolines for efficiency's sake. But for C this would not be 
acceptable.

Any alternatives that would work for Harvard Architecture devices such 
as the AVR would be welcome.

Eric

Re: Feature request: Globalize symbol

[Hans-Peter Nilsson]

> 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 that we have a long history of adding flawed features
> that have to be later removed.

That describes some GCC extensions rather than features invoked
by explicit options, IIRC.

>  So I want you to try to think about
> anything that might possibly go wrong now instead of just assuming that
> it will obviously work.

In general, those are my concerns too.  But we're not at the
stage when precise definition is called for: I wanted to get
initial reaction.  That was negative.  Further discussion is
academic.

>  You are proposing a new kind of option, one
> that first translates symbolnames to variable names, and then changes
> their linkage, so you need to carefully define exactly how this works in
> all cases, and how it interacts with all existing gcc features.

The proposal is an instrumentation feature that is explicitly
invoked, not a GCC extension that can appear anywhere in the
source.  For such a feature, I think it would (for example) be
enough to define a domain where the feature works, and declare
everything else a (possibly undetected) error.

> The original poster mentioned an interaction with .hidden, so you need
> to define how the feature of removing static interacts with visibility
> attributes.

Yes, I asked Hugo to describe interaction of the feature with
the visibility attribute.  Unfortunately that was not defined in
the necessarily explicit terms in the proposal.  Fortunately, no
intricate rules are needed: visibility attributes do not appear
on things declared static.  (They are ignored with a warning;
best would be to force the "default" visibility when the option
is in effect, with or without the current warning.)

> There may also be other issues that need to be dealt with.  It would be
> useful to browse the C standard and the list of gcc extensions to look
> for possible issues that might need to be dealt with.  It may also be
> useful to look at how gcc internals handle static and look for potential
> problems.

Good implementation advice.

> I am not opposed to the feature in principle.

Thanks.  This is the level of answer I actually was looking for.

>  I just think that you
> aren't being vigorous enough in defining it.

I am not defining it.  You're too vigorous trying to make me do
that at this time.

My intention was to correct misunderstandings about what the
feature was *intended* to do.  This in order to get informed
feedback whether this feature would be acceptable for FSF GCC.
It seems in doing that, I have been dragged into discussion
about a formal precise definition of the feature.  That's
premature.

I would of course look into neighboring areas and options if I
would implement this.  Right now, I think that will not happen.

I do know of the getting-detailed-definitions-of-GCC-extensions
problem; please assume I have the same basic concerns as anyone
here.  Really no need to reiterate on that.

(Any/All: If you now want to discuss whether a full
implementation, specification and documentation *must* be
present in order to get an *initial* reaction on a GCC feature,
please change the subject.  Please.)

>  I'd like to see a formal
> specification of what the option does, both in how the symbolname to
> variable mapping works, and in how the static removal works.

In due time.  Having said all that, the intended main effect
would be the equivalent of "#define static" (or "-Dstatic=") in
C when there are only file-scope statics (i.e. not affecting
function-level statics).  That's all at the moment.  Everything
else is corner cases and side-effects; details to be defined.

> Richard however does appear to be objecting in principle, which is
> another matter.

Alas.  Still, that answer was at the "right" level for me at
this time.  I have to discuss this with Hugo when he's back
from vacation.

brgds, H-P

Re: Non-bootstrap build status reports

[Janis Johnson]

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 apologize for being way being on updating the build
status reports.

I'm willing to add entries for cross builds as long as there is
information in the report about the build, host, and target triples.
If the build report mentions necessary tweaks, the entry notes that.

> Also, it might be nice to have a record of negative build reports.  For
> instance, the build status page might have section for negative builds
> listing reports of failed builds that might serve as a quick means to
> determine the health of a broken port.

Bug reports are better, although I'm willing to consider this.

Janis

Re: Questions about trampolines

[Robert Dewar]

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 implementation of trampolines on
many systems, even I believe requiring system calls in some cases, and
yes, this is horribly expensive!
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 special kind of pointer
I suppose, but it seems the feature is so little used in C that this would
be overkill.

Re: Questions about trampolines

[Mike Stump]

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 the removal of the feature from C.  We have 
gotten one bug report asking for them to go away, so that error 
reporting is more accurate, start a function, error out faster saying 
there is a missing '}'...

Re: Merging calls to `abort'

[Joe Buck]

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 different solution to this problem: changing all
> > the abort calls so that (1) they can't be cross-jumped and (2) they  
> > use even more space.  If everyone follows your recommendation, not 
> > only will no abort calls ever be cross jumped, but the net result will
> > be to make the compiled program even bigger than it would have been.

Debugging information uses massive space, therefore almost no users of
free software have debugging information in the executables that they run
daily.  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
report from a user that "the program died with an abort", he or she has to
debug from scratch, only to find out in many cases that it's a known bug,
already fixed in CVS for the next release, information that would have
been revealed immediately by the output of fancy_abort.  With a pointer to
the exact function, file, and line where the crash occurred, in many cases
the user can use a search engine to find an already-existing discussion of
the bug, and possibly even a workaround.

To me, this means that fancy_abort is clearly preferable to abort, and the
win is so large that I would urge all GNU projects to adopt it
immediately.  As Steven points out, the cost to the developer can be as
little as the inclusion of one line in a widely-included header.

It is true that the strings for __FILE__ and __FUNCTION__ require space,
but this is negligible, especially due to sharing.  

All that said, however, Steven, you are being unnecessarily rude and
dismissive:

> You don't have to change any abort calls in the source code, you just
> replace the definition of abort.  You are greatly exaggerating the
> increase in space my recommendation would cause.  And you complain
> that no abort calls can ever be crossjumped, but you are saying that
> should not ever happen anyway, so your point is moot.
> 
> Your silly overstatement of the burden on the user to change the
> program, and the point that crossjumping is a useless optimization,
> are the only things that makes no sense.

Please watch the tone; we can disagree without being insulting.  Please
especially don't insult the man who started GCC in the first place, even
if you're sure he is wrong.

Re: Merging calls to `abort'

[Richard Kenner]

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 report from a user that "the program died with an abort", he or
she has to debug from scratch, only to find out in many cases that
it's a known bug, already fixed in CVS for the next release,
information that would have been revealed immediately by the output of
fancy_abort.

I agree.  I find this a vert strong argument.

Re: Questions about trampolines

[Waldek Hebisch]

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 (theoretical?) alternatives to trampolines exist? I.e. something
>   that does not generate code runtime.

The main purpose of tramplines is to provide a function with extra
data privete to given instance (and to do this at runtime). There
are some alternatives: `thick pointers' and double indirection. 
Both methods associate extra data with function pointers and require
different way of calling functions via function pointers. Thick 
pinters carry extra data together with the pointer, making calls 
faster but copying slower. Also, thick pointers beeing bigger then
machine addressess are not compatible with usual pointers.
Double indirection slows calls, but pinter is compatible with 
machine address and cheaper to copy around. 

If a language wants to interface with C then the language must
use the same representaition of function pointers as C. For standard C
thick pointers are both inefficient and may break a lot of real code.
Double indirection is quite compatible (and IFAIK is used by some
system ABI-s). Still for C double indirection is more expensive
then calling pointer directly. And for established targets ABI is
fixed, so there is no choice...

One can always imagine different implementation. For example, assign
invalid adresses to function pointer and use a signal handler to
sort out what should be called and with what arguments. But I will
not advocate such implementation.

So given constraint of compatibility with existing C implementations 
trampolines look like the best choice. Tramplines are in fact standard
implementation technique in functional languages, especially for
interfacing with C.

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
extra functionality, beyond what nested functions give. For example
they can be used to "partially apply" a function, giving it some
frozen arguments, and providing the rest at call time.

There is some connestion with objects: "partial applicatin" can produce
pointer to a method compatible with usual calling convention.


-- 
  Waldek Hebisch
[EMAIL PROTECTED] 

Re: Merging calls to `abort'

[Dale Johannesen]

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 program that includes ,
which some would consider a good reason not to prefer it.
I believe the cross-jumping should definitely be done with -Os; the 
optimization
makes a useful contribution to reducing code size, which the user has 
told us
is important to him.  Other than that, I don't care much.  (I have 
debugged
problems where the debugger was showing me the wrong abort call, and
this was annoying, but not something I couldn't deal with.  Typically 
you
just have to stop on the right call to the function that's calling 
abort.)

Re: Questions about trampolines

[Robert Dewar]

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
extra functionality, beyond what nested functions give. For example
they can be used to "partially apply" a function, giving it some
frozen arguments, and providing the rest at call time.
Trampolines do of course have to be handled in a stack like fashion (to
get recursion right), so you have to be very careful about allocation and
deallocation in this separate area. And you still have the cache problem,
so I don't see what it buys.

Re: Questions about trampolines

[Alexander Strange]

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 opinion, but I've yet to find an actual piece of code in a
real project that uses that extension.
I use it; it involves writing less code than a userdata pointer would. 
I admit that I've never encountered any other code that takes the 
address of local functions, and I could easily use inlining to stop it 
using trampolines.

Re: Questions about trampolines

[Michael N. Moran]

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 accessing instruction
and data space.

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 talking about a system that loads
programs at run-time.
These devices typically have a "large" amount of Flash ROM
(32K-68K bytes), and a smaller amount of RAM (512-2K bytes).
Don't hold me to these numbers, but you get the idea.
--
Michael N. Moran   (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
 and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1

Re: Questions about trampolines

[E. Weddington]

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 talking about a system that loads
programs at run-time.
Right. These address spaces are totally seperate. There is no way to run 
code in the data space (RAM). One can store some data in the program 
space (Flash), but it requires special instruction sequences to access it.


These devices typically have a "large" amount of Flash ROM
(32K-68K bytes), and a smaller amount of RAM (512-2K bytes).
Don't hold me to these numbers, but you get the idea.
Code space (Flash): 8K-256K bytes
Data space (SRAM): 512-8K bytes
Non-volatile EEPROM: 256-4K bytes (typically half of SRAM, also requires 
special instruction sequences to access).

Eric

Re: Questions about trampolines

[Waldek Hebisch]

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 trampolines in separate area may provide
> > extra functionality, beyond what nested functions give. For example
> > they can be used to "partially apply" a function, giving it some
> > frozen arguments, and providing the rest at call time.
> 
> Trampolines do of course have to be handled in a stack like fashion (to
> get recursion right), so you have to be very careful about allocation and
> deallocation in this separate area. And you still have the cache problem,
> so I don't see what it buys.
> 

1) the stack can be execute protected, so simple buffer overflow exploits
   will be detected. On i386 one can use segment register to make stack
   non-executable and still use trampolines

2) On machine with separate code and data areas trampolines can be in 
   (writable) code space. Of course it does not help if all code space
   in non-writable.

3) One limits contention between code and data cache during calls. Of
   course cost of generating trampoline may be slightly higher, but the
   cost of call is likely to be lower. Even for for generation, one can
   limit number of `mprotect' call from one per tramoline to one per page
   (which is likely to be much smaller).

4) One gets extra functionality (partial application), which may
   significanlty reduce need for pointers to nested functions. Namely,
   trampolines for partial application may be re-used much easier
   then nested functions (which have to be regenerated when entering
   the scope)


-- 
  Waldek Hebisch
[EMAIL PROTECTED] 

Re: Merging calls to `abort'

[Richard Stallman]

'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 -- debugging is hard,
debugging optimized programs is harder.

There is no room in software development for responding to a bug
report with "tough".  That attitude is incompatible with trying to
serve the users.

Ideally we would satisfy all wishes of all users.  That is not
feasible; there are times when we must say no, and for good reason.
But we should never say no when we can easily and painlessly say yes.
(And when we have to say no, we should never say "tough".)

GCC should handle the case of programs using `abort' in the best way
that is reasonably feasible.  GCC should handle each and every case in
the most useful way that is reasonably feasible.

This case would not be worth a lot of work.  But since we know exactly
what would make it better, and it is a small change, there's no reason
not to do it.

Re: Merging calls to `abort'

[Richard Stallman]

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
cross-jumping.

So the conclusion doesn't change: it makes no sense to insist on
cross-jumping abort calls to make the binary smaller, and tell the
user to deal with the resulting inconvenience with a technique that
makes the binary even bigger.

Re: Merging calls to `abort'

[Richard Stallman]

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 I've found, from experience, that the
line number alone is not very useful.  It is the first necessary piece
of information, but very rarely will anyone track down the bug from
that alone.

If the user can provide a test case to reproduce the bug, then the
maintainers can debug the problem without further help from the user.
Back when handling GCC bug reports was my responsibility, the first
thing I did was run the test case under GDB and examine the data.  I
found this to be the most efficient way to proceed.  To stare at the
code first was not time-effective.

If the user can't provide a test case, the only one who can debug the
problem is the user, on the user's machine.  Either the user does it
(perhaps under the guidance of others) or it doesn't get done.  This
needs to be done with the debugger.

Therefore, it is very useful for the debugger to show the correct line
number.

With your suggestion, "those who want to use a fancy_abort" are the
ones who pay.

With all due respect, I don't think they will pay anything.  Changing
GCC not to cross-jump abort calls will have no effect on programs that
use fancy_abort.

This change will make GCC handle one fairly common case better, it
will not handle any case worse, and it is easy to do.  That is good
reason to make the change.

Re: Merging calls to `abort'

[Joe Buck]

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 basis than this.

As I recall, in the old days you (RMS) used to do user polls on occasion.
Would you consider doing it in this case?  That is, is it appropriate
for the GNU project to place naked aborts in its programs?  Or is it
preferable to do a bit more work and provide the user with more
information in the case of a program crash, even at the price of adding
a kilobyte or two to the program's size?

>   If
> cross jumping makes debugging harder, tough -- debugging is hard,
> debugging optimized programs is harder.
> 
> There is no room in software development for responding to a bug
> report with "tough".  That attitude is incompatible with trying to
> serve the users.

In this discussion it appears that the term "user" is overloaded.
RMS appears to be using it to refer to the user of GCC, but I am
concerned about the effect on end users.

I would not say "tough", as it's impolite.  However, I believe that
putting a plain "abort()" in a program does not serve the users of that
program, cross-jumping or no cross-jumping.  This is because almost all
the users run stripped binaries, meaning that this discussion is moot to
them: they get a mysterious crash that they cannot debug.

An abort message that tells the user the exact location of the crash
can speed up the communication between user and developer, and may save
lots of time if it immediately reveals that the bug report is a
duplicate.

> Ideally we would satisfy all wishes of all users.  That is not
> feasible; there are times when we must say no, and for good reason.
> But we should never say no when we can easily and painlessly say yes.
> (And when we have to say no, we should never say "tough".)

But what are you saying to those users who don't like it that GNU programs
abort silently when they discover bugs in themselves?  Aren't you saying
"tough" in a somewhat more polite way?

> GCC should handle the case of programs using `abort' in the best way
> that is reasonably feasible.  GCC should handle each and every case in
> the most useful way that is reasonably feasible.
> 
> This case would not be worth a lot of work.  But since we know exactly
> what would make it better, and it is a small change, there's no reason
> not to do it.

Yes, it's possible to treat "abort" specially and to avoid crossjumping
optimization in that particular case.  It is not cost-free, as a test
needs to be performed every time there is a candidate for cross-jumping,
but for all I know this cost is negligible.  We might well want to do it.

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.

Re: Merging calls to `abort'

[Joe Buck]

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_abort functions because I've found, from experience, that the
> line number alone is not very useful.  It is the first necessary piece
> of information, but very rarely will anyone track down the bug from
> that alone.

Agreed.  However, if this is a frequently reported bug, then the
developer might well know, as soon as he sees the error from the second
user, that it is the same bug, while if there is only an abort there
is less information.  If the developer does not answer the bug report
promptly, the user might still find information about the crash with
a web search, because a search for

tool: fatal internal error in frobnicate.c, frob_all_elements, line 372

is likely to find something if it exists, while a search for

abort - core dumped

is less likely to find something useful.

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.

Re: Merging calls to `abort'

[Mark Mitchell]

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; 
it also saves time, because space *is* time on modern processors, where 
every bit of icache counts.

I don't see any reason for GCC to treat "abort" specially.  It should at 
least treat all "noreturn" functions equivalently.  But, beyond that, 
I'm a user who would rather than crossjumping be run on calls to 
"abort".  I use "abort" only when I've already issued a useful 
diagnostic, and want to dump core.  Otherwise, I use "assert", or an 
exception.  So, I would not support this change.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Merging calls to `abort'

[Jeffrey A Law]

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 period of time,
> and yet feel differently.
Right.


> Agreed.  However, if this is a frequently reported bug, then the
> developer might well know, as soon as he sees the error from the second
> user, that it is the same bug, while if there is only an abort there
> is less information. 
Right.  Through the years I've found file and line number information
provided by a fancy abort have been enough to identify the more common
internal failures in releases and even from time to time internal 
failures during development.

>  If the developer does not answer the bug report
> promptly, the user might still find information about the crash with
> a web search, because a search for
> 
> tool: fatal internal error in frobnicate.c, frob_all_elements, line 372
> 
> is likely to find something if it exists, while a search for
> 
> abort - core dumped
> 
> is less likely to find something useful.
Absolutely.

I also think that the message itself is more comforting than just a
plain abort.  ie, if we look at the range of failures some are more
reassuring/friendly than others.  On one end we have naked segmentation
faults.  On the other we might have diagnostics which indicate that
a particular feature is unimplemented.  In between we have a naked
abort and an abort with a potentially useful message indicating
file/line information and possibly the cause of the abort.



> 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 function
attribute which prevented cross jumping to any function with
the attribute set.

Jeff

Re: Merging calls to `abort'

[Eric Christopher]

> > 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 function
> attribute which prevented cross jumping to any function with
> the attribute set.

I think it makes sense to just not crossjump noreturn attribute
functions if we're going to do this.

-eric

Re: Questions about trampolines

[Russell Shaw]

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 *not* RAM. We're not talking about a system that loads
programs at run-time.
Right. These address spaces are totally seperate. There is no way to run 
code in the data space (RAM). One can store some data in the program 
space (Flash), but it requires special instruction sequences to access it.


These devices typically have a "large" amount of Flash ROM
(32K-68K bytes), and a smaller amount of RAM (512-2K bytes).
Don't hold me to these numbers, but you get the idea.
Code space (Flash): 8K-256K bytes
Data space (SRAM): 512-8K bytes
Non-volatile EEPROM: 256-4K bytes (typically half of SRAM, also requires 
special instruction sequences to access).
How is a pointer to a nested function any different to a pointer to
an un-nested function? Why need trampolines?

Re: Questions about trampolines

[Joe Buck]

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 functions.

An alternative implementation technique is to give pointers to functions
that can be nested two words, one to point to the function, the other
to pass the "display", a data structure that allows variables in outer
functions to be accessed.

Re: Merging calls to `abort'

[Daniel Jacobowitz]

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 treating abort
> > specially within GCC, I think we'd be better off with a function
> > attribute which prevented cross jumping to any function with
> > the attribute set.
> 
> I think it makes sense to just not crossjump noreturn attribute
> functions if we're going to do this.

I'm inclined to agree.  I also think that we should be making this
change, at least at -O2.

I talked to Mark Mitchell about this briefly this evening.  He pointed
out that __cxa_throw is a noreturn function where crossjumping is often
useful.  So perhaps we do need an attribute, but I'm not sure which way
the default should go.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: documentation on writing testcases?

[Ben Elliston]

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 ernest once I 
complete my study at the end of June).

Ben

Re: `make uninstall' and GCC

[Ben Elliston]

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 be installing GCC via a packaging system these days, so make uninstall 
is used even less.

Ben

Re: Questions about trampolines

[Robert Dewar]

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 separate instructions for accessing instruction
and data space.

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 talking about a system that loads
programs at run-time.
In that case, you have to use function descriptors I think there
is no way around this.
These devices typically have a "large" amount of Flash ROM
(32K-68K bytes), and a smaller amount of RAM (512-2K bytes).
Don't hold me to these numbers, but you get the idea.

Re: Questions about trampolines

[Robert Dewar]

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.