From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Nick Duffek , "Christopher G. Faylor" Cc: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Thu, 09 Nov 2000 22:18:00 -0000 Message-id: <3A0B91AB.1815BC89@cygnus.com> References: <20001109222231.A26675@redhat.com> <200011100503.eAA53pT24667@rtl.cygnus.com> X-SW-Source: 2000-11/msg00058.html Nick Duffek wrote: > > On 9-Nov-2000, Christopher Faylor wrote: > > >I've been told in private email that I mustn't use alloca > > Say it ain't so! > > >Alloca is useful. > > Especially because multi-arching is turning small compile-time constants > into run-time variables all over the place. If we can't use alloca, then > wherever there's something like this: > > char rawbuf[MAX_REGISTER_SIZE]; This is being converted to char *rawbuf = alloca (MAX_REGISTER_SIZE); with the knowledge that it probably isn't going to work on some hosts. The conversion is tolerated because a more significant change incures greater risk (bigger chance of someone botching it :-). At the time it was agreed that such alloca() calls should eventually be eliminated. Andrew >From cgf@cygnus.com Thu Nov 09 22:20:00 2000 From: "Christopher G. Faylor" To: Andrew Cagney Cc: Nick Duffek , gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Thu, 09 Nov 2000 22:20:00 -0000 Message-id: <20001110012016.A18577@redhat.com> References: <20001109222231.A26675@redhat.com> <200011100503.eAA53pT24667@rtl.cygnus.com> <3A0B91AB.1815BC89@cygnus.com> X-SW-Source: 2000-11/msg00059.html Content-length: 865 On Fri, Nov 10, 2000 at 05:11:55PM +1100, Andrew Cagney wrote: >Nick Duffek wrote: >> >> On 9-Nov-2000, Christopher Faylor wrote: >> >> >I've been told in private email that I mustn't use alloca >> >> Say it ain't so! >> >> >Alloca is useful. >> >> Especially because multi-arching is turning small compile-time constants >> into run-time variables all over the place. If we can't use alloca, then >> wherever there's something like this: >> >> char rawbuf[MAX_REGISTER_SIZE]; > >This is being converted to > > char *rawbuf = alloca (MAX_REGISTER_SIZE); > >with the knowledge that it probably isn't going to work on some hosts. >The conversion is tolerated because a more significant change incures >greater risk (bigger chance of someone botching it :-). > >At the time it was agreed that such alloca() calls should eventually be >eliminated. Why? cgf >From ac131313@cygnus.com Thu Nov 09 22:27:00 2000 From: Andrew Cagney To: Christopher Faylor Cc: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Thu, 09 Nov 2000 22:27:00 -0000 Message-id: <3A0B93BE.C434189D@cygnus.com> References: <20001109212032.A26464@redhat.com> X-SW-Source: 2000-11/msg00060.html Content-length: 1639 Christopher Faylor wrote: > > A patch that I recently submitted to gdb-patches used the alloca () > function to allocate memory. I've been told in private email that I > mustn't use alloca because "stack corruption problems are harder to > debug" than heap corruption problems. The principal reason is that it is non-portable. Some hosts have fairly arbitrary limits on how much can be alloca()'d. A black/white please don't use this is easier to follow than some vague ``only when'' guideline .... Yes, multi-arch has put us into the grey. Other secondary factors in the decision would have included the observation that alloca (and stack arrays) (well actually just C :-) can lead to nasy buffer overflow bugs that corrupt the stack. Andrew > 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? > > It is my assertion that the amount of bookkeeping and overhead required > to use malloc in a way that is analogous with alloca essentially > nullifies the "harder to debug" argument. malloc requires a free and > many times, in gdb context, the only way to guarantee a free is with the > use of the cleanup function. Any time you add the complexity of > something like 'cleanup()' (or whatever other mechanism you use to > ensure that what you malloc is automatically freed) you can't claim to > have reduced debugging problems. Speaking of free, with alloca you > don't have memory leaks. With malloc, you do. > > If alloca is bad, then why are local arrays and pointers to local > variables and parameters ok? > > Inquiring minds... > > cgf >From eliz@delorie.com Fri Nov 10 02:39: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 02:39:00 -0000 Message-id: <200011101039.FAA29785@indy.delorie.com> References: <3A0B4885.B2384AE7@netscape.com> X-SW-Source: 2000-11/msg00061.html Content-length: 636 > Date: Thu, 09 Nov 2000 16:59:49 -0800 > From: bstell@netscape.com (Brian Stell) > > The strings could be UTF-8, UTF-16, some kind > of C++ object, etc. > > What provision is there for Gdb users to extend > Gdb to display an application specific item like > this? One way is to call the functions in the debuggee that convert these strings to a printable representation, then print the result; the GDB command "print" can do that. It is highly likely that in a program which supports non-ASCII characters you will have functions which convert non-ASCII strings to a printable representation and back. Does that solve the problem? >From eliz@delorie.com Fri Nov 10 02:39:00 2000 From: Eli Zaretskii To: cgf@redhat.com Cc: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 02:39:00 -0000 Message-id: <200011101039.FAA29788@indy.delorie.com> References: <20001109212032.A26464@redhat.com> X-SW-Source: 2000-11/msg00062.html Content-length: 392 > 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. >From eliz@delorie.com Fri Nov 10 02:40:00 2000 From: Eli Zaretskii To: cgf@redhat.com Cc: meissner@cygnus.com, gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 02:40:00 -0000 Message-id: <200011101040.FAA29793@indy.delorie.com> References: <20001109212032.A26464@redhat.com> <20001109213750.28987@cse.cygnus.com> <20001109222231.A26675@redhat.com> X-SW-Source: 2000-11/msg00063.html Content-length: 979 > Date: Thu, 9 Nov 2000 22:22:31 -0500 > From: Christopher Faylor > > You can, of course, have array overruns with an alloca'ed buffer just > like you can with a malloced array. IMHO, buffer overruns are irrelevant to this issue, since they happen with automatic arrays as well, and are equally hard (or simple) to track. > Hmm. I think that Purify actually does help track down stack corruption > so there is at least one tool for this. I've never used Electric Fence > but I would be surprised if it was completely trivial to use and I would > be equally surprised if linking with Electric Fence automatically > pinpointed heap problems in every case. You are right, as long as my experience goes. Malloc debuggers are anything but trivial to use, and some large programs which allocate memory all the time, such as Emacs, are practically impossible to debug using these tools, at least those of them which use page protection to catch buffer overruns. >From jimb@zwingli.cygnus.com Fri Nov 10 06:21:00 2000 From: Jim Blandy To: gdb@sources.redhat.com Cc: Andrew Cagney , Nick Duffek Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 06:21:00 -0000 Message-id: References: <20001109222231.A26675@redhat.com> <200011100503.eAA53pT24667@rtl.cygnus.com> <3A0B91AB.1815BC89@cygnus.com> <20001110012016.A18577@redhat.com> X-SW-Source: 2000-11/msg00064.html Content-length: 263 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. Of course, strictly typed mechanisms, like GCC's dynamically sized arrays, are preferable, but not widely available. >From cgf@redhat.com Fri Nov 10 08:16:00 2000 From: Chris Faylor To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 08:16:00 -0000 Message-id: <20001110111651.A19503@redhat.com> References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> X-SW-Source: 2000-11/msg00065.html Content-length: 581 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? cgf >From cgf@redhat.com Fri Nov 10 08:27:00 2000 From: Christopher Faylor To: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 08:27:00 -0000 Message-id: <20001110112720.A19671@redhat.com> References: <20001109222231.A26675@redhat.com> <200011100503.eAA53pT24667@rtl.cygnus.com> <3A0B91AB.1815BC89@cygnus.com> <20001110012016.A18577@redhat.com> X-SW-Source: 2000-11/msg00066.html Content-length: 501 On Fri, Nov 10, 2000 at 09:21:51AM -0500, 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. > >Of course, strictly typed mechanisms, like GCC's dynamically sized >arrays, are preferable, but not widely available. I agree with this. I use dynamically sized arrays in cygwin because it is guaranteed to be compiled by gcc. Are dynamically sized arrays part of C99 by any chance? cgf >From fnasser@cygnus.com Fri Nov 10 08:42:00 2000 From: Fernando Nasser To: gdb@sources.redhat.com Cc: Eli Zaretskii Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 08:42:00 -0000 Message-id: <3A0C2588.89C2B603@cygnus.com> References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> X-SW-Source: 2000-11/msg00067.html Content-length: 1229 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? > Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to our interpreter's command loops or the garbage collection becomes somewhat random (it will only happen when you call alloca() for allocating some other stuff and will only clean what was allocated by code that executed on frames below the current stack position. I think we have this bug when alloca() gets used right now. (Nothing difficult, we just need to remember to do it) -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From cgf@redhat.com Fri Nov 10 08:46:00 2000 From: Christopher Faylor To: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 08:46:00 -0000 Message-id: <20001110114629.A19882@redhat.com> References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> <3A0C2588.89C2B603@cygnus.com> X-SW-Source: 2000-11/msg00068.html Content-length: 1331 On Fri, Nov 10, 2000 at 11:42:48AM -0500, Fernando Nasser 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? >> > >Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to >our interpreter's command loops or the garbage collection becomes somewhat >random (it will only happen when you call alloca() for allocating some >other stuff and will only clean what was allocated by code that executed on frames >below the current stack position. > >I think we have this bug when alloca() gets used right now. > >(Nothing difficult, we just need to remember to do it) % fgrep 'alloca (0)' *.c gnu-regex.c: alloca (0); gnu-regex.c: alloca (0); gnu-regex.c: alloca (0); regcache.c: alloca (0); top.c: alloca (0); cgf >From bstell@ix.netcom.com Fri Nov 10 08:51:00 2000 From: bstell@ix.netcom.com To: Eli Zaretskii Cc: bstell@netscape.com, gdb@sources.redhat.com, Fernando Nasser Subject: Re: extending Gdb to display app specific data Date: Fri, 10 Nov 2000 08:51:00 -0000 Message-id: <3A0C2791.A33BE9AC@ix.netcom.com> References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> X-SW-Source: 2000-11/msg00069.html Content-length: 865 My goal is to reduce the "initial cognitive learning barrier" and allow non experts to inspect data and help debug. Eli Zaretskii wrote: > One way is to call the functions in the debuggee that convert these > strings to a printable representation, then print the result ... > Does that solve the problem? If it can be put in a ".gdb_display_funcs" and the user can type "p unichar_ptr" and it works then that would be great. Having to remember a display function puts the knowledge burden on the (non expert) user. The user has to know the data type and then know the display function. Imagine the frustration if one had to type "p display_string(ptr)" every time they wanted to see a ascii string. In just the same way I'm looking for a way for the users not to have to remember "p display_unichar(unichar_ptr)". Doesn't gdb already know the data type? >From meissner@cygnus.com Fri Nov 10 09:05:00 2000 From: Michael Meissner To: Fernando Nasser Cc: gdb@sources.redhat.com, Eli Zaretskii Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 09:05:00 -0000 Message-id: <20001110120544.43205@cse.cygnus.com> References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> <3A0C2588.89C2B603@cygnus.com> X-SW-Source: 2000-11/msg00070.html Content-length: 1721 On Fri, Nov 10, 2000 at 11:42:48AM -0500, Fernando Nasser 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? > > > > Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to > our interpreter's command loops or the garbage collection becomes somewhat > random (it will only happen when you call alloca() for allocating some > other stuff and will only clean what was allocated by code that executed on frames > below the current stack position. > > I think we have this bug when alloca() gets used right now. > > (Nothing difficult, we just need to remember to do it) Note, that liberty's alloca will only be used if the host compiler is not GCC, which probably makes it even harder to remember to use.... BTW, there are systems out there that even's liberty's alloca will not work on (due to either using a cactus stack or allocating the stack in pieces from the heap). -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: meissner@redhat.com phone: +1 978-486-9304 Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482 >From fnasser@cygnus.com Fri Nov 10 09:08:00 2000 From: Fernando Nasser To: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 09:08:00 -0000 Message-id: <3A0C2B9D.61C451F3@cygnus.com> References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> <3A0C2588.89C2B603@cygnus.com> <20001110114629.A19882@redhat.com> X-SW-Source: 2000-11/msg00071.html Content-length: 1965 Christopher Faylor wrote: > > On Fri, Nov 10, 2000 at 11:42:48AM -0500, Fernando Nasser 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? > >> > > > >Warning: if the "liberty" alloca() is used a "alloca(0)" must be added to > >our interpreter's command loops or the garbage collection becomes somewhat > >random (it will only happen when you call alloca() for allocating some > >other stuff and will only clean what was allocated by code that executed on frames > >below the current stack position. > > > >I think we have this bug when alloca() gets used right now. > > > >(Nothing difficult, we just need to remember to do it) > > % fgrep 'alloca (0)' *.c > gnu-regex.c: alloca (0); > gnu-regex.c: alloca (0); > gnu-regex.c: alloca (0); > regcache.c: alloca (0); > top.c: alloca (0); 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. (Or not used the darn thing!) -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From fnasser@cygnus.com Fri Nov 10 09:13:00 2000 From: Fernando Nasser To: bstell@ix.netcom.com Cc: Eli Zaretskii , bstell@netscape.com, gdb@sources.redhat.com Subject: Re: extending Gdb to display app specific data Date: Fri, 10 Nov 2000 09:13:00 -0000 Message-id: <3A0C2CB5.BF3CAB97@cygnus.com> References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> X-SW-Source: 2000-11/msg00072.html Content-length: 1183 Perhaps what you would like is a new output format specifiers to the print and x commands? bstell@ix.netcom.com wrote: > > My goal is to reduce the "initial > cognitive learning barrier" and > allow non experts to inspect data > and help debug. > > Eli Zaretskii wrote: > > One way is to call the functions in the debuggee that convert these > > strings to a printable representation, then print the result ... > > Does that solve the problem? > > If it can be put in a ".gdb_display_funcs" > and the user can type "p unichar_ptr" > and it works then that would be great. > > Having to remember a display function puts > the knowledge burden on the (non expert) > user. The user has to know the data type > and then know the display function. > Imagine the frustration if one had to type > "p display_string(ptr)" every time they > wanted to see a ascii string. > > In just the same way I'm looking for > a way for the users not to have to > remember "p display_unichar(unichar_ptr)". > > Doesn't gdb already know the data type? -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From Eric.Mure@france.sun.com Fri Nov 10 11:03:00 2000 From: eric mure To: gdb@sourceware.cygnus.com Subject: relocated local static variables Date: Fri, 10 Nov 2000 11:03:00 -0000 Message-id: <3A0C468A.E084918E@sunchorus.france.sun.com> X-SW-Source: 2000-11/msg00073.html Content-length: 2097 Hello, We are porting GDB to debug MIPS relocatables. We use -gdwarf-2, and most of debugging features works, notably functions and global variables (.data and .bss) can be accessed correctly after relocation (we use the objfile_relocate function to relocate the symbols of the executable file in memory after it has been loaded on the target). But we have some problems with local static variables. For example: main() { static int localStaticBss; ... } section .text is relocated at 0xfa964000 section .bss is relocated at 0xfa963070 (gdb)info address localStaticBss Symbol "localStaticBss" is static storage at address 0xfa964000. ==> So gdb thinks that localStaticBss is in the .text section! Dumping the Debug Attributes with dwarfdump: <2>< 155> DW_TAG_variable DW_AT_name localStaticBss DW_AT_decl_file 1 DW_AT_decl_line 19 DW_AT_type <200> DW_AT_location DW_OP_addr 0 Dumping the Symbol Table with nm: [ 2] b 0x00 localStaticBss.3 section .bss (gdb)info address localStaticBss.3 Symbol "localStaticBss.3" is static storage at address 0xfa963070. So GDB does not see that these 2 symbols are in fact the same variable. First, I incorporated the following patch: [PATCH RFA] dwarf2read.c: symbol relocation in new_symbol() which relocate address of symbol by the base address of the section it is in rather than always using the base address of the .text section. The function fixup_symbol_section call lookup_minimal_symbol ("localStaticBss", ...) But only "localStaticBss.3" is in the minimal symbol table (name generated by the assembler). So, the section field can't be updated. The .symtab and .debug_info sections contains enough informations to retrieve such value, but it doesn't seem to be the right way to do. Is there any patch or future implementation which deals with that ? note: we use gcc version 2.8.1 and GNU gdb version 20001004 -gstab is unsupported by this compiler. Eric. >From ebachalo@redhat.com Fri Nov 10 11:07:00 2000 From: Eric Bachalo To: jtc@redback.com Cc: Rudy Folden , gdb@sourceware.cygnus.com Subject: Re: libremote activation Date: Fri, 10 Nov 2000 11:07:00 -0000 Message-id: <3A0C4780.EA77ECE4@redhat.com> References: <3A0B0F63.254C569A@redhat.com> X-SW-Source: 2000-11/msg00074.html Content-length: 2283 First, apologies for not getting libremote sources out to the public yet. We fully plan to release all libremote sources to the public in the near future. The only reason we haven't to date is a lack of available resources to do it properly. Libremote is our effort to make a standard framework under a single set of sources for handling GDB remote protocol on the target side. We plan on releasing the code under a BSD like license. This will eliminate worries of linking this code with third party proprietary libraries. Eric Bachalo Director of Engineering Red Hat, Inc. "J.T. Conklin" wrote: > > >>>>> "Rudy" == Rudy Folden writes: > Rudy> Michael Snyder and I are working on what we believe to be the > Rudy> first native version of libremote for an embedded Linux system. > > Thanks for the explanation of what libremote is. Note that I make the > following suggestions knowing pretty much nothing about it. > > * If GDB, or the remote protocol, needs to be changed in any way to > support automatic activation of libremote, there needs to be more > disclosure about what it is. Even if it's kept redhat proprietary, > we'll need a spec so we can properly interface with it. > > * Your comments about starting libremote via an inetd like mechanism > vs. starting it at runtime seem somewhat contradictory. Yes, many > embedded systems have little memory, but the footprint of a debug > agent should be very small (10-20K). If you have room to run an > inetd like program, you should be able to run a debug agent as well. > Note, if inetd is spawning the program, it's going to take the same > amount of memory as if it was spawned at system startup. > > * Your comments about libremote stopping after GDB exits and needing > an instance for each program under debug are manifestations of > design bugs in the remote protocol. A single debug agent should be > able to be started at system bringup; support debugging any number > of processes (and any number of threads); and should not exit when > GDB quits. In order for the debug agent not to have to manage > multiple communication channels, that might be handled by a host- > side proxy. > > --jtc > > -- > J.T. Conklin > RedBack Networks >From fnasser@cygnus.com Fri Nov 10 11:44:00 2000 From: Fernando Nasser To: jtc@redback.com Cc: Rudy Folden , gdb@sourceware.cygnus.com Subject: Re: libremote activation Date: Fri, 10 Nov 2000 11:44:00 -0000 Message-id: <3A0C5019.F4539C79@cygnus.com> References: <3A0B0F63.254C569A@redhat.com> X-SW-Source: 2000-11/msg00075.html Content-length: 1646 JT, The libremote that Rudy was talking about is just some piece of software to allow targets that do not speak the target protocol to be connected to gdb. It is a middleware, a translator, that talks the remote protocol on one side and the alien protocol on the other. This way one don't have to make gdb talk funky proprietary protocols or link it to non-GPLed libraries. The remote protocol is all we need. As Eric said in the previous message, it will soon be available as Open Source, as everything else that we do. At that time, people will be able to start making suggestions, contributing with code and, most importantly, using it. It will come with some example directories and a few interfaces already in there so that it will make it easier for people to understand how it works and how it should be used. We have tried it to connect to stand alone simulators, to a proprietary CORBA interface to a Hardware Emulator and so on. Michael Snyder stretched the concept and reimplemented gdbserver using it (that was what Rudy was refering to). Someone else made it run inside an embedded device! You can make virtually anything speak the remote protocol now. As soon as the general public start playing with it we will see amazing things being connected to GDB, all using the remote protocol. Note that this being a library, we can eventually even have a new protocol and these targets have just to be relinked to a new version of the libremote library. We will have fun with it. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9 >From eliz@delorie.com Fri Nov 10 12:00:00 2000 From: Eli Zaretskii To: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Fri, 10 Nov 2000 12:00:00 -0000 Message-id: <200011101959.OAA00112@indy.delorie.com> References: <20001109212032.A26464@redhat.com> <200011101039.FAA29788@indy.delorie.com> <20001110111651.A19503@redhat.com> X-SW-Source: 2000-11/msg00076.html Content-length: 421 > Date: Fri, 10 Nov 2000 11:16:51 -0500 > From: Chris Faylor > > > >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? I don't think this should be an issue. >From eliz@delorie.com Fri Nov 10 12:09:00 2000 From: Eli Zaretskii To: bstell@ix.netcom.com Cc: bstell@netscape.com, gdb@sources.redhat.com, fnasser@cygnus.com Subject: Re: extending Gdb to display app specific data Date: Fri, 10 Nov 2000 12:09:00 -0000 Message-id: <200011102009.PAA00126@indy.delorie.com> References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> X-SW-Source: 2000-11/msg00077.html Content-length: 1369 > From: bstell@ix.netcom.com > Date: Fri, 10 Nov 2000 08:51:29 -0800 > > Eli Zaretskii wrote: > > One way is to call the functions in the debuggee that convert these > > strings to a printable representation, then print the result ... > > Does that solve the problem? > > If it can be put in a ".gdb_display_funcs" > and the user can type "p unichar_ptr" > and it works then that would be great. That would require GDB to support every possible charset out there; Unicode is not the only game in town. While it would be extremely nice if GDB knew about all the charsets and their encodings, it looks like a terribly huge job to add that. > Having to remember a display function puts > the knowledge burden on the (non expert) > user. The user has to know the data type > and then know the display function. I'm assuming that a person who debugs a program knows something about its internals, including how it represents non-ASCII characters. > Imagine the frustration if one had to type > "p display_string(ptr)" every time they > wanted to see a ascii string. That's exactly what I need to do when, for example, I need to print a Lisp data structure, such as an alist, when I debug Emacs. > Doesn't gdb already know the data type? GDB knows the data type, but it doesn't necessarily know how to generate a human-readable representation of that data type. >From eliz@delorie.com Fri Nov 10 12:10:00 2000 From: Eli Zaretskii To: fnasser@cygnus.com Cc: bstell@ix.netcom.com, bstell@netscape.com, gdb@sources.redhat.com Subject: Re: extending Gdb to display app specific data Date: Fri, 10 Nov 2000 12:10:00 -0000 Message-id: <200011102010.PAA00131@indy.delorie.com> References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <3A0C2CB5.BF3CAB97@cygnus.com> X-SW-Source: 2000-11/msg00078.html Content-length: 331 > Date: Fri, 10 Nov 2000 12:13:25 -0500 > From: Fernando Nasser > > Perhaps what you would like is a new output format specifiers to the > print and x commands? That would be the desired solution, I guess. But it requires GDB to know about UTF-8, UTF-16, and all the other possible encoding like ISO-2022. >From bstell@netscape.com Fri Nov 10 16:08:00 2000 From: bstell@netscape.com (Brian Stell) To: gdb@sources.redhat.com Subject: Re: extending Gdb to display app specific data Date: Fri, 10 Nov 2000 16:08:00 -0000 Message-id: <3A0C8E19.A8A6D355@netscape.com> References: <3A0B4885.B2384AE7@netscape.com> <200011101039.FAA29785@indy.delorie.com> <3A0C2791.A33BE9AC@ix.netcom.com> <200011102009.PAA00126@indy.delorie.com> X-SW-Source: 2000-11/msg00079.html Content-length: 681 We all agree that gdb by itself cannot display every data type that will come along. What I'm looking for is a way for an expert user to tell gdb how to display a given type. This way within a community of developers the expert users can setup display routines for the complex data types in that environment and everyone else can view the data in gdb. For example, in the Mozilla development world there are a large number of developers and a variety of string formats (PRUnichar=UTF16, nsString=C++ object, etc.) and more are expected in the future (e.g.: a compressed format). It is easy to say RTFM but it would be more effective to say "copy this file to your home dir".