From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: gdb@sources.redhat.com, "Christopher G. Faylor" Cc: Eli Zaretskii Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 21:34:00 -0000 Message-id: <3A0CD8C1.426EA933@cygnus.com> References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> X-SW-Source: 2000-11/msg00084.html 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 > >> > >> 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 To: Jim Blandy Cc: gdb@sources.redhat.com, Nick Duffek 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> 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 To: Fernando Nasser 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 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 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 > 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 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 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> <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 > > 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 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 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> 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" 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 >>>> >>>>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 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 To: bstell@ix.netcom.com Cc: gdb@sources.redhat.com, Fernando Nasser Subject: Re: extending Gdb to display app specific data Date: Sat, 11 Nov 2000 10:51:00 -0000 Message-id: 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> <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?)