Re: alloca is bad?

[Andrew Cagney <ac131313@cygnus.com>]

Chris Faylor wrote:
> 
> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
> >> Date: Thu, 9 Nov 2000 21:20:32 -0500
> >> From: Christopher Faylor <cgf@redhat.com>
> >>
> >> I was surprised by this assertion and so I thought I'd ask for a
> >> consensus here.  Should the use of alloca be deprecated in gdb?
> >
> >In my experience, there's nothing wrong with alloca as long as it is
> >used for allocating small buffers.  The only consideration is that not
> >every platform supports alloca.
> 
> But, since alloca is already entrenched in gdb and available in liberty
> I don't think this is an issue, is it?

There are a many entrenched practices in GDB and many of those we don't
want to perpetuate.  Typically, these were either viewed as innocent
short-cuts or simply as good ideas.  In hindsight (we've 15 years worth
now :-) these practices turned out to be somewhat misguided.  Part of
our penance is that on-going maintenance expense we incur when ever we
touch the code.

Consider Peter S's example as a case in point - it looked harmless :-)

	enjoy,
		Andrew
From ac131313@cygnus.com Fri Nov 10 22:13:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: gdb@sources.redhat.com, Nick Duffek <nsd@redhat.com>
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 22:13:00 -0000
Message-id: <3A0CE1DB.6F6B1E93@cygnus.com>
References: <20001109222231.A26675@redhat.com> <200011100503.eAA53pT24667@rtl.cygnus.com> <3A0B91AB.1815BC89@cygnus.com> <20001110012016.A18577@redhat.com> <npem0j52m8.fsf@zwingli.cygnus.com>
X-SW-Source: 2000-11/msg00085.html
Content-length: 1888

Jim Blandy wrote:
> 
> I think alloca is terribly useful.  I have every intention of using it
> the next time it's appropriate.  We should not reject new uses of
> alloca.

To decide it is appropriate I think there need to be some clear and
objective guidelines.  Otherwise people submitting code are going to run
into the problem that their submition is being accepted or dismissed
based on the arbitrary wim of the reviewer.  It also means that what
ever decision is reached it has some rationale behind it - otherwize the
alloca debate will just flare up again in another 6 months.

The discussion has already identified the issues:

	o	need to call alloca(0) somewhere
		(perhaphs do_cleanups() should do this :-)

	o	total stack bound of <2mb

	o	(from memory) limit of 64k
		on a single stack frame
		(some rs6000 platforms)

	o	the suggestion that some platforms
		don't support even libiberty's alloca.

		I'd be very interested in knowing the
		details of this.

> Of course, strictly typed mechanisms, like GCC's dynamically sized
> arrays, are preferable, but not widely available.

(Personally, since C doesn't do bounds checking, I think dyamic arrays
are only slightly better :-)

This brings up an additional, possibly relevent, point.  Given the code:

	int a[size];
vs
	int *const a = alloca (size * sizeof (int));
or	int *const a = (int *) alloca (size & sizeof (int));

(er and there is even one in the above and no it wasn't contrived!) the
latter definitely has more potential error points (both when being
written and being maintained).  Coding pratices that minimize a
programmers error rate should be considered.

One ``cute trick'' I'm guilty of is probably worth considering:

	#define XCALLOC(N,TYPE) ((TYPE *) xmalloc ((N) * sizeof (TYPE)))
	int *a = XCALLOC (size, int);

(which works because GDB has a zero tolerance policy towards basic
warnings).

	Andrew
From ac131313@cygnus.com Fri Nov 10 22:17:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 22:17:00 -0000
Message-id: <3A0CE2E6.D5500C70@cygnus.com>
References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> <3A0C2588.89C2B603@cygnus.com> <20001110114629.A19882@redhat.com> <3A0C2B9D.61C451F3@cygnus.com>
X-SW-Source: 2000-11/msg00086.html
Content-length: 703

Fernando Nasser wrote:

> That takes care of the CLI commands.  (MI and Insight are probably broken)
> 
> Any other interpreter that uses the libgdb exported functions instead
> of the CLI execute_command will have to do the same.  How can we control
> that this is done if a script, for instance, calls random libgdb functions?
> 
> Maybe we will have to add a call to alloca(0) to every libgdb call.

I'd argue that the analysis of this error demonstrates that people are
going to forget to call alloca(0).  It is after all an obscure querk of
libiberty and not exactly a normal C convention.

Based on that, inserting an alloca(0) call in every libgdb function
probably is best :-(

	enjoy,
		Andrew
From eliz@delorie.com Fri Nov 10 23:32:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: bstell@netscape.com
Cc: gdb@sources.redhat.com
Subject: Re: extending Gdb to display app specific data
Date: Fri, 10 Nov 2000 23:32:00 -0000
Message-id: <200011110732.CAA00523@indy.delorie.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <200011102009.PAA00126@indy.delorie.com> <3A0C8E19.A8A6D355@netscape.com>
X-SW-Source: 2000-11/msg00087.html
Content-length: 348

> Date: Fri, 10 Nov 2000 16:08:57 -0800
> From: bstell@netscape.com (Brian Stell)
> 
> What I'm looking for is a way for an expert user to tell
> gdb how to display a given type.

Could you please post a list of the types which you'd like to be able
to display, and tell how each one of these types should look on the
screen when displayed by GDB?
From eliz@delorie.com Fri Nov 10 23:33:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: meissner@cygnus.com
Cc: bstell@netscape.com, gdb@sources.redhat.com
Subject: Re: extending Gdb to display app specific data
Date: Fri, 10 Nov 2000 23:33:00 -0000
Message-id: <200011110733.CAA00526@indy.delorie.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <200011102009.PAA00126@indy.delorie.com> <3A0C8E19.A8A6D355@netscape.com> <20001110191444.26019@cse.cygnus.com>
X-SW-Source: 2000-11/msg00088.html
Content-length: 738

> From: Michael Meissner <meissner@cygnus.com>
> Date: Fri, 10 Nov 2000 19:14:44 -0500
> 
> Do like GCC does and include functions in your code that take your type as an
> argument, and print the type in question to stdout (or stderr).  For example
> within gcc, there is debug_rtx, which takes a rtx pointer, and prints out the
> value in tree format, and similarly debug_tree which does it for tree nodes.
> To further enhance the debugging experience, the .gdbinit command includes
> several shortcuts (like pr/pt) that pass the last value to the above
> functions.

Emacs does the same; see the function `debug_print'.

For example, if I want to print an alist kept in a C variable
my_alist, I say:

 (gdb) call debug_print(my_alist)
From eliz@delorie.com Fri Nov 10 23:33:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: bstell@netscape.com
Cc: gdb@sources.redhat.com
Subject: Re: extending Gdb to display app specific data
Date: Fri, 10 Nov 2000 23:33:00 -0000
Message-id: <200011110733.CAA00529@indy.delorie.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <200011102009.PAA00126@indy.delorie.com> <3A0C8E19.A8A6D355@netscape.com> <20001110191444.26019@cse.cygnus.com> <3A0C935B.AE3C0AF9@netscape.com>
X-SW-Source: 2000-11/msg00089.html
Content-length: 451

> Date: Fri, 10 Nov 2000 16:31:23 -0800
> From: bstell@netscape.com (Brian Stell)
> 
> So how do we do this without requiring the end
> user to know the exact data type of a variable
> in any routine they pass thru and without requiring
> the end user memorize the routine names?

The function (from the debugged program) that is used to print the
data type could find out the type itself.  That's what `debug_print'
in Emacs does, albeit indirectly.
From eliz@delorie.com Fri Nov 10 23:34:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: jimb@cygnus.com, gdb@sources.redhat.com, nsd@redhat.com
Subject: Re: alloca is bad?
Date: Fri, 10 Nov 2000 23:34:00 -0000
Message-id: <200011110733.CAA00532@indy.delorie.com>
References: <20001109222231.A26675@redhat.com> <200011100503.eAA53pT24667@rtl.cygnus.com> <3A0B91AB.1815BC89@cygnus.com> <20001110012016.A18577@redhat.com> <npem0j52m8.fsf@zwingli.cygnus.com> <3A0CE1DB.6F6B1E93@cygnus.com>
X-SW-Source: 2000-11/msg00090.html
Content-length: 603

> Date: Sat, 11 Nov 2000 17:06:19 +1100
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> 	o	total stack bound of <2mb

The default stack size of DJGPP programs is 512KB.  It is allocated at
startup time in its entirety, and cannot be changed while the program
runs.

If we want to be more defensive against possible stack overflows due
to alloca, we need to use getrlimit.

In any case, we should be able to define some maximum size that is
allowed to be used with alloca, and write it up in the coding
standards.  Then code accept/reject criteria are no longer arbitrary,
they are corporate policy ;-)
From nsd@redhat.com Sat Nov 11 09:08:00 2000
From: Nick Duffek <nsd@redhat.com>
To: cagney@cygnus.com
Cc: gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Sat, 11 Nov 2000 09:08:00 -0000
Message-id: <200011111713.eABHDrN15135@rtl.cygnus.com>
References: <3A0CE1DB.6F6B1E93@cygnus.com>
X-SW-Source: 2000-11/msg00091.html
Content-length: 996

On 11-Nov-2000, Andrew Cagney wrote:

>This brings up an additional, possibly relevent, point.  Given the code:

>	int a[size];

>vs
>	int *const a = alloca (size * sizeof (int));
>or	int *const a = (int *) alloca (size & sizeof (int));

>(er and there is even one in the above and no it wasn't contrived!) the
>latter definitely has more potential error points (both when being
>written and being maintained).  Coding pratices that minimize a
>programmers error rate should be considered.

That's one of the strongest arguments in favor of alloca over malloc.  The
programmer error potential in these two lines of code:

	int *const a = alloca (size * sizeof (int));
	int *const a = malloc (size * sizeof (int));

is exactly the same, but adding free() in the malloc case adds much more
potential for errors, as demonstrated by the popularity of tools for
finding memory leaks.  The malloc case gets even more error-prone where we
need to check for non-local exits and add cleanup chains.

Nick
From bstell@ix.netcom.com Sat Nov 11 09:47:00 2000
From: bstell@ix.netcom.com
To: gdb@sources.redhat.com
Cc: Fernando Nasser <fnasser@cygnus.com>
Subject: Re: extending Gdb to display app specific data
Date: Sat, 11 Nov 2000 09:47:00 -0000
Message-id: <3A0D8620.F4510B5@ix.netcom.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <200011102009.PAA00126@indy.delorie.com> <3A0C8E19.A8A6D355@netscape.com> <20001110191444.26019@cse.cygnus.com> <3A0C935B.AE3C0AF9@netscape.com> <m3u29fxqu6.fsf@dan2.cygnus.com>
X-SW-Source: 2000-11/msg00092.html
Content-length: 464

Thanks.

These are both good ideas which I will pursue.

Daniel Berlin wrote:
> Um, use a single routine name, overloaded for the
> data types you want to print?
> You did say you were using C++, right?


Eli Zaretskii wrote:
> The function (from the debugged program) that is used to print the
> data type could find out the type itself.  That's what `debug_print'
> in Emacs does, albeit indirectly.

(Fernando, can we use this in the Insight tooltips/bubbles?)
From cgf@cygnus.com Sat Nov 11 10:07:00 2000
From: "Christopher G. Faylor" <cgf@cygnus.com>
To: gdb@sources.redhat.com
Subject: Re: alloca is bad?
Date: Sat, 11 Nov 2000 10:07:00 -0000
Message-id: <20001111130703.A24382@redhat.com>
References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> <3A0CD8C1.426EA933@cygnus.com>
X-SW-Source: 2000-11/msg00093.html
Content-length: 1277

On Sat, Nov 11, 2000 at 04:27:29PM +1100, Andrew Cagney wrote:
>Chris Faylor wrote:
>> On Fri, Nov 10, 2000 at 05:39:29AM -0500, Eli Zaretskii wrote:
>>>>Date: Thu, 9 Nov 2000 21:20:32 -0500
>>>>From: Christopher Faylor <cgf@redhat.com>
>>>>
>>>>I was surprised by this assertion and so I thought I'd ask for a
>>>>consensus here.  Should the use of alloca be deprecated in gdb?
>>>
>>>In my experience, there's nothing wrong with alloca as long as it is
>>>used for allocating small buffers.  The only consideration is that not
>>>every platform supports alloca.
>> 
>>But, since alloca is already entrenched in gdb and available in liberty
>>I don't think this is an issue, is it?
>
>There are a many entrenched practices in GDB and many of those we don't
>want to perpetuate.  Typically, these were either viewed as innocent
>short-cuts or simply as good ideas.  In hindsight (we've 15 years worth
>now :-) these practices turned out to be somewhat misguided.  Part of
>our penance is that on-going maintenance expense we incur when ever we
>touch the code.
>
>Consider Peter S's example as a case in point - it looked harmless :-)

I don't think that the fact that you can cut yourself with a knife means
that you eliminate all sharp objects from your premises.

YMMV,
cgf
From bstell@ix.netcom.com Sat Nov 11 10:50:00 2000
From: bstell@ix.netcom.com
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: bstell@netscape.com, gdb@sources.redhat.com
Subject: Displaying Unicode
Date: Sat, 11 Nov 2000 10:50:00 -0000
Message-id: <3A0D94F6.9FC95EE8@ix.netcom.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <200011102009.PAA00126@indy.delorie.com> <3A0C8E19.A8A6D355@netscape.com> <200011110732.CAA00523@indy.delorie.com>
X-SW-Source: 2000-11/msg00094.html
Content-length: 2271

[This came from a different thread: ]
[Was: extending Gdb to display app specific data)]

Eli Zaretskii wrote:
> Could you please post a list of the types which you'd like to be able
> to display, and tell how each one of these types should look on the
> screen when displayed by GDB?

Lets look at Unicode.

UCS-2
=============
Each character is 16 bits which allows programs to (more 
easily) handle languages with more than 255 characters 
(eg: Japanese). The ascii values are basically extended 
to 16 bits. For example "A" which is 0x41 in ascii would 
be 0x0041 in UCS-2. 

The simplest UCS-2 display would be to display the ascii 
as ascii and the non-ascii as hex. This way the non 
internalization (i18n) engineers get to continue to see
the strings as before. The i18n engineers will have to
look up the values (which they often need to do anyway).

A more sophisticated display routine would check if the 
non ascii was displayable in the current locale and if so
would convert it to the current locale encoding for
display. This way developers that can read Japanese, etc.
can see (hopefully something close to) the intended
text.

To my knowledge there is not a universally used type for 
UCS-2 but we could require that for Gdb display the app 
use "UCS2 *".

UTF-16
========
For purposes of this discussion it is the same as UCS-2.
UTF-16 supports greater than 64K characters by allowing 
an extended value to be composed of two 16 bit characters.
Display the same as UCS-2.

To my knowledge there is not a universally used type for 
UTF-16 but we could require that for Gdb display the app 
use "UTF16 *".

UTF-8
=========
An alternate (8 bit multibyte) encoding, Popular because
UTF-8 does not have any 0 bytes in the data stream. For 
display convert it to UCS-2 and then display the UCS-2.

To my knowledge there is not a universally used type for 
UTF-8 but we could require that for Gdb display the app 
use "UTF8 *".


Here is a UCS-2 display routine I use:
==============================================
void
dump_UCharString(const UChar *uChar_str)
{
  while (*uChar_str) {
    if (*uChar_str < 0x7F) {
      printf("%c", *uChar_str);
    }
    else {
      printf("\\x%02x%02x ", (*uChar_str)>>8, (*uChar_str)&0xFF);
    }
    uChar_str++;
  }
}
From dberlin@redhat.com Sat Nov 11 10:51:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: bstell@ix.netcom.com
Cc: gdb@sources.redhat.com, Fernando Nasser <fnasser@cygnus.com>
Subject: Re: extending Gdb to display app specific data
Date: Sat, 11 Nov 2000 10:51:00 -0000
Message-id: <m3y9yqqr41.fsf@dan2.cygnus.com>
References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <200011102009.PAA00126@indy.delorie.com> <3A0C8E19.A8A6D355@netscape.com> <20001110191444.26019@cse.cygnus.com> <3A0C935B.AE3C0AF9@netscape.com> <m3u29fxqu6.fsf@dan2.cygnus.com> <3A0D8620.F4510B5@ix.netcom.com>
X-SW-Source: 2000-11/msg00095.html
Content-length: 1275

bstell@ix.netcom.com writes:

> Thanks.
> 
> These are both good ideas which I will pursue.

Also, if you let us know what datatypes you are specifically referring
to,  we can help.

For instance, c++ vectors (maps broke recently, i'm working on it),
you can use gdb convenience variables and iterators,
like

set $a = ourVector.begin()

print *$a
print *$a++
etc

It'll print the right thing, calling the right functions, etc.

Same with 
print ourVector[0].

It'll call operator[] properly, and print the result.

As soon as i fix maps, you'll be able to do the same 

print ourMap["hello"]


C++ strings vary in representation, but we could always make it call
.c_str() when you print it, or something.
Then you run into the problem that people debugging c++ standard
libraries won't be able to view the internals of their strings.

--Dan

> 
> Daniel Berlin wrote:
> > Um, use a single routine name, overloaded for the
> > data types you want to print?
> > You did say you were using C++, right?
> 
> Eli Zaretskii wrote:
> > The function (from the debugged program) that is used to print the
> > data type could find out the type itself.  That's what `debug_print'
> > in Emacs does, albeit indirectly.
> 
> (Fernando, can we use this in the Insight tooltips/bubbles?)