From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stan Shebs To: brendan@dgs.monash.edu.au Cc: gdb@sourceware.cygnus.com Subject: Re: GDB Manual Date: Mon, 30 Aug 1999 16:32:00 -0000 Message-id: <199908302332.QAA09891@andros.cygnus.com> References: <37CB1097.7B80AE8E@dgs.monash.edu.au> X-SW-Source: 1999-q3/msg00248.html Date: Tue, 31 Aug 1999 09:15:36 +1000 From: Brendan Simon > Just wanted to let everybody know that I've just committed a major > reorg of the GDB manual. What I've done is to create a new chapter > "Configurations" (suggestions for better title welcome), that contains > all configuration/platform-specific detail. Up until now, the > information has been somewhat randomly scattered through the manual, > or not recorded at all. How about "target details", "target specifics" or "target specific details". Something with "target" in the name. The chapter includes native config details too, so while it's technically correct to say it's target-specific, I wouldn't want native debugging folks to skip over the chapter because it doesn't sound relevant. I note that the corresponding GCC manual section is labeled "Hardware Models and Configurations"... Stan >From shebs@cygnus.com Mon Aug 30 16:38:00 1999 From: Stan Shebs To: jkamdar@emc.com Cc: brendan@dgs.monash.edu.au, gdb@sourceware.cygnus.com Subject: Re: GDB Manual Date: Mon, 30 Aug 1999 16:38:00 -0000 Message-id: <199908302338.QAA09912@andros.cygnus.com> References: <37CB1308.AD458749@emc.com> X-SW-Source: 1999-q3/msg00249.html Content-length: 376 Date: Mon, 30 Aug 1999 19:26:00 -0400 From: Jayesh Kamdar Where can I get that manual from or is it part of the tar file ? In the tar file; look at gdb/doc/gdb.texinfo. You can make info files or DVI using "make info" and "make dvi", respectively. (Do not run the formatting programs directly! You'll miss out on some key defns.) Stan >From kevinb@cygnus.com Mon Aug 30 17:09:00 1999 From: Kevin Buettner To: Stan Shebs Cc: gdb@sourceware.cygnus.com Subject: Re: GDB Manual Date: Mon, 30 Aug 1999 17:09:00 -0000 Message-id: <990831000922.ZM14053@ocotillo.lan> References: <199908302338.QAA09912@andros.cygnus.com> X-SW-Source: 1999-q3/msg00250.html Content-length: 501 On Aug 30, 4:38pm, Stan Shebs wrote: > In the tar file; look at gdb/doc/gdb.texinfo. You can make info files > or DVI using "make info" and "make dvi", respectively. (Do not run > the formatting programs directly! You'll miss out on some key defns.) Is it possible to do "make html" yet? In the past, I've used texi2html by hand to create html versions of the manual, but I wouldn't want to miss out on some crucial definitions... Kevin -- Kevin Buettner kev@primenet.com, kevinb@cygnus.com >From shebs@cygnus.com Mon Aug 30 17:27:00 1999 From: Stan Shebs To: kevinb@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: GDB Manual Date: Mon, 30 Aug 1999 17:27:00 -0000 Message-id: <199908310027.RAA09964@andros.cygnus.com> References: <990831000922.ZM14053@ocotillo.lan> X-SW-Source: 1999-q3/msg00251.html Content-length: 646 Date: Mon, 30 Aug 1999 17:09:22 -0700 From: Kevin Buettner On Aug 30, 4:38pm, Stan Shebs wrote: > In the tar file; look at gdb/doc/gdb.texinfo. You can make info files > or DVI using "make info" and "make dvi", respectively. (Do not run > the formatting programs directly! You'll miss out on some key defns.) Is it possible to do "make html" yet? In the past, I've used texi2html by hand to create html versions of the manual, but I wouldn't want to miss out on some crucial definitions... It must work - I just tried it in my sandbox, filled my objdir full of .html files... Stan >From jsm@cygnus.com Mon Aug 30 17:46:00 1999 From: Jason Molenda To: Kevin Buettner Cc: Stan Shebs , gdb@sourceware.cygnus.com Subject: Re: GDB Manual Date: Mon, 30 Aug 1999 17:46:00 -0000 Message-id: <19990830174636.A546@cygnus.com> References: <199908302338.QAA09912@andros.cygnus.com> <990831000922.ZM14053@ocotillo.lan> X-SW-Source: 1999-q3/msg00252.html Content-length: 900 On Mon, Aug 30, 1999 at 05:09:22PM -0700, Kevin Buettner wrote: > Is it possible to do "make html" yet? I added the (non-standard) target a couple of months ago. It is used by a script which keeps the GDB manual up-to-date on the GDB web page. "What's that," you say, "the GDB manual is on-line and yet no one remembers it? How could that be?" It's certainly a good question--I sent an announcement about it to the GDB mailing lists when I set it up. So, as a reminder, you can see the current GDB manual by starting at the GDB web page, http://sourceware.cygnus.com/gdb/ It'll have Stan's changes after the next snapshot is imported into the Sourceware CVS repository[1] and the nightly doco-updater-script runs. [1] Of _course_ everyone knows that the GDB development sources are available by anonymous read-only CVS in addition to the weekly snapshots. Jason Free the Software! >From ac131313@cygnus.com Mon Aug 30 18:55:00 1999 From: Andrew Cagney To: Martin Baulig Cc: gdb@sourceware.cygnus.com Subject: Re: libGDB architecture Date: Mon, 30 Aug 1999 18:55:00 -0000 Message-id: <37CB35A6.5BC8EB33@cygnus.com> References: <37C204C1.E81875D9@cygnus.com> <86wvudkjsx.fsf@localhost.uni-trier.de> X-SW-Source: 1999-q3/msg00253.html Content-length: 256 Martin Baulig wrote: > Is there already some code available somewhere ? I just (well in the last week) posted code for a bit of the event framework. And am now going over the code for the builder so that some of that can be posted / discussed. Andrew >From tromey@cygnus.com Mon Aug 30 20:35:00 1999 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: "u" alias Date: Mon, 30 Aug 1999 20:35:00 -0000 Message-id: <87iu5wsjns.fsf@cygnus.com> X-SW-Source: 1999-q3/msg00254.html Content-length: 447 Tonight I discovered that the command "u" is an alias for "until". I don't like this. I've literally never used the "until" command. However, I do use the "up" command every single time I run gdb (I can't remember not using it), and I expected "u" to alias "up" by default. Can we change this? This is ancient code, so I'm sure I'll hear the "somebody relies on this" argument. But does anybody really? Can we take a poll or something? Tom >From ac131313@cygnus.com Mon Aug 30 21:42:00 1999 From: Andrew Cagney To: Todd Whitesel Cc: GDB Developers Subject: Re: libGDB architecture Date: Mon, 30 Aug 1999 21:42:00 -0000 Message-id: <37CB5CDF.207E943@cygnus.com> References: <199908270529.WAA08670@alabama.wrs.com> X-SW-Source: 1999-q3/msg00255.html Content-length: 1557 Todd Whitesel wrote: > > > In the first case, there is a chance that the target could die part way > > through an exchange. That in turn could cause GDB to hang until a timer > > kicks in. It was felt that the probability of this was low and the > > amount of effort needed to handle this case providing marginal return. > > > > As a second pass (or as contributed code) this can be re-worked into a > > simpler interface. > > Reasonable enough. > > I must say though, one of my biggest complaints against the innards of MULTI > was that the synchronous heritage from ptrace() was rampant and was lousy for > embedded, where we can have targets dying and the debugger UI freezing solid > while a compile is going on in another window ... customers really hate that. > > Various attempts to solve this often resulted in the UI event loops being > re-entered, which has its own host of dangers. I fought hard for the idea > of state-machining tasks that block in vulnerable places, so we could just > call everything from the top of the event loop and not have problems. The > people whose backing I needed for it pooh-poohed the idea for a couple years, > but about the time I was quitting I discovered that the guy promoted to head > up MULTI had quietly started working on it and was mostly finished. I believe that Elena has been hitting her head against that one for some time. In the longer term I agree that things like remote.c and ser-* should be made into separate state machines along the lines you suggest. Just not this week :-) Andrew >From ac131313@cygnus.com Mon Aug 30 21:47:00 1999 From: Andrew Cagney To: Martin Baulig Cc: gdb@sourceware.cygnus.com, gnome-debugger-list@gnome.org Subject: Re: libGDB architecture - Guile interface #2 Date: Mon, 30 Aug 1999 21:47:00 -0000 Message-id: <37CB5E27.A0E4536B@cygnus.com> References: <86zoz9kjuz.fsf@localhost.uni-trier.de> X-SW-Source: 1999-q3/msg00256.html Content-length: 972 Martin Baulig wrote: > > Hello, > > after my previos mail with a general introduction about the current > state of my guile interface here comes some kind of real proposal ... > > Rather than some kind of abstract structure like > > > (breakpoint > > ((number 1) > > (type "breakpoint") > > (disp "keep") > > (enabled "y") > > (addr "0x0000003d") > > (func "main") > > (file "hello.c" 3))) > > we should IMHO use record types for this - for instance > > ==== > (define-public gdb-frame-record > (make-record-type "gdb-frame-record" > '(type level file line mid pc function language))) > > (define-public gdb-breakpoint-record > (make-record-type "gdb-breakpoint-record" > '(number type disp enabled addr func file line))) I think what you are saying is that the scheme implementation would do this while other targets/scripting languages could do it differently? This is scheme specific. Andrew >From jtc@redback.com Mon Aug 30 21:56:00 1999 From: jtc@redback.com (J.T. Conklin) To: tromey@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: "u" alias Date: Mon, 30 Aug 1999 21:56:00 -0000 Message-id: <5m7lmco8f3.fsf@jtc.redbacknetworks.com> References: <87iu5wsjns.fsf@cygnus.com> X-SW-Source: 1999-q3/msg00257.html Content-length: 1429 >>>>> "Tom" == Tom Tromey writes: Tom> Tonight I discovered that the command "u" is an alias for Tom> "until". I don't like this. I've literally never used the Tom> "until" command. However, I do use the "up" command every single Tom> time I run gdb (I can't remember not using it), and I expected Tom> "u" to alias "up" by default. Can we change this? For what it's worth, I don't remember ever using the 'until' command, much less the 'u' alias. That being said, I believe single character commands are 'special' (for lack of a better word) and that there should be a compelling reason for creating one. Not every command is deserving of single character aliases --- only the most useful and most used commands. Like you, I use up in nearly every debug session and think it passes the usefulness/usability test. Another characteristic that single character aliases should have is a symmetry with other similar commands. The commands s / n / c / r / and u cover nearly all the commands that resume target execution. If there was a single letter command for walking up the stack frame, I would expect a complementary single letter command for walking down the stack frame. Using 'u' for up would break the symmetry of the exec commands, and I think the prospect of using 'd' for down is even less likely since 'd' is the breakpoint delete alias. --jtc -- J.T. Conklin RedBack Networks >From law@cygnus.com Mon Aug 30 22:20:00 1999 From: "Jeffrey A. Law" To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: "u" alias Date: Mon, 30 Aug 1999 22:20:00 -0000 Message-id: <199908310520.WAA29755@rtl.cygnus.com> References: <87iu5wsjns.fsf@cygnus.com> <5m7lmco8f3.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q3/msg00258.html Content-length: 957 In article < 5m7lmco8f3.fsf@jtc.redbacknetworks.com > you write: > >>>>>> "Tom" == Tom Tromey writes: >Tom> Tonight I discovered that the command "u" is an alias for >Tom> "until". I don't like this. I've literally never used the >Tom> "until" command. However, I do use the "up" command every single >Tom> time I run gdb (I can't remember not using it), and I expected >Tom> "u" to alias "up" by default. Can we change this? > >For what it's worth, I don't remember ever using the 'until' command, >much less the 'u' alias. I use u(ntil) regularly :-) One that did disappear that I used to use was e(nable), but presuably it wasn't symmetric with d(elete). Anyway, the reason behind the message is to make sure we do not allow a single person's (or small group) opinion to sway gdb's UI. Particularly when *changing existing* behavior. As for me personally, muscle memory can be retrained, it just takes a little time. jeff >From ac131313@cygnus.com Mon Aug 30 23:00:00 1999 From: Andrew Cagney To: gdb@sourceware.cygnus.com Subject: -Werror -Wformat -Wimplicit Date: Mon, 30 Aug 1999 23:00:00 -0000 Message-id: <37CB6DBE.2083662F@cygnus.com> X-SW-Source: 1999-q3/msg00259.html Content-length: 1339 Just FYI, The next snap (Jason only just made one) is very likely to be buildable with the configuration option: --enable-build-warnings=-Werror\ ,-Wimplicit\ ,-Wreturn-type\ ,-Wcomment\ ,-Wtrigraphs\ ,-Wformat\ ,-Wparentheses\ ,-Wpointer-arith\ ,-Woverloaded-virtual I've cleaned up numerous targets and, for them, the source code contains *ZERO* warnings of the types listed above. Assuming that your host's header files are in good condition, it shouldn't take much for a few maintainers to wack their native build into similar shape. For the curious. The full list looks like: enable_build_warnings=`echo -Werror\ \ ,$W\ ,-Wimplicit\ ,-Wreturn-type\ ,$Wunused\ ,$Wswitch\ ,-Wcomment\ ,-Wtrigraphs\ ,-Wformat\ ,$Wchar$subscripts\ ,$Wuninitialized\ ,-Wparentheses\ ,$Wtemplate$debugging\ \ ,$Wtraditional\ ,$Wshadow\ ,$Wid$clash$len\ ,-Wpointer-arith\ ,$Wcast$qual\ ,$Wcast$align\ ,$Wwrite$strings\ ,$Wconversion\ ,$Waggregate$return\ ,$Wstrict$prototypes\ ,$Wmissing$prototypes\ ,$Wmissing$declarations\ ,$Wredundant$decls\ ,$Wnested$externs\ ,$Wenum$clash\ ,-Woverloaded-virtual\ ,$Winline\ so while there is a long way to go, the list of those working is very useful (namely -Wformat, -Wimplicit, -Wparen and -Wcomment - especially -Wformat!). enjoy, Andrew >From MartinB2@deutschepost.de Tue Aug 31 01:09:00 1999 From: "Baulig, ITS P A800, TR" To: Martin Baulig , "'Andrew Cagney'" Cc: gdb@sourceware.cygnus.com Subject: AW: libGDB architecture - Guile interface #2 Date: Tue, 31 Aug 1999 01:09:00 -0000 Message-id: X-SW-Source: 1999-q3/msg00260.html Content-length: 1423 Yes, of cause it is scheme specific. Other scripting languages such as Perl or python can define their own objects. Martin > ---------- > Von: Andrew Cagney[SMTP:ac131313@cygnus.com] > Gesendet: Dienstag, 31. August 1999 05:46 > An: Martin Baulig > Cc: gdb@sourceware.cygnus.com; gnome-debugger-list@gnome.org > Betreff: Re: libGDB architecture - Guile interface #2 > > Martin Baulig wrote: > > > > Hello, > > > > after my previos mail with a general introduction about the current > > state of my guile interface here comes some kind of real proposal ... > > > > Rather than some kind of abstract structure like > > > > > (breakpoint > > > ((number 1) > > > (type "breakpoint") > > > (disp "keep") > > > (enabled "y") > > > (addr "0x0000003d") > > > (func "main") > > > (file "hello.c" 3))) > > > > we should IMHO use record types for this - for instance > > > > ==== > > (define-public gdb-frame-record > > (make-record-type "gdb-frame-record" > > '(type level file line mid pc function language))) > > > > (define-public gdb-breakpoint-record > > (make-record-type "gdb-breakpoint-record" > > '(number type disp enabled addr func file line))) > > > I think what you are saying is that the scheme implementation would do > this while other targets/scripting languages could do it differently? > > This is scheme specific. > > Andrew > >From MartinB2@deutschepost.de Tue Aug 31 01:12:00 1999 From: "Baulig, ITS P A800, TR" To: "'Andrew Cagney'" , "'gdb@sourceware.cygnus.com'" Subject: AW: libGDB architecture Date: Tue, 31 Aug 1999 01:12:00 -0000 Message-id: X-SW-Source: 1999-q3/msg00261.html Content-length: 613 Oh fine. Since I'm already working on a guile interface to gdb, I'd be glad to help you with the scheme-specific builder code. Martin > ---------- > Von: Andrew Cagney[SMTP:ac131313@cygnus.com] > Gesendet: Dienstag, 31. August 1999 02:53 > An: Martin Baulig > Cc: gdb@sourceware.cygnus.com > Betreff: Re: libGDB architecture > > Martin Baulig wrote: > > > Is there already some code available somewhere ? > > I just (well in the last week) posted code for a bit of the event > framework. And am now going over the code for the builder so that some > of that can be posted / discussed. > > Andrew > >From jtc@redback.com Tue Aug 31 08:53:00 1999 From: jtc@redback.com (J.T. Conklin) To: martin@home-of-linux.org Cc: "'gdb@sourceware.cygnus.com'" Subject: Re: AW: libGDB architecture Date: Tue, 31 Aug 1999 08:53:00 -0000 Message-id: <5mbtbodk13.fsf@jtc.redbacknetworks.com> References: X-SW-Source: 1999-q3/msg00262.html Content-length: 1314 >>>>> "Martin" == Baulig, ITS P A800, TR writes: Martin> Oh fine. Since I'm already working on a guile interface to Martin> gdb, I'd be glad to help you with the scheme-specific builder Martin> code. Martin, Can you tell me a bit more about your GUILE interface project? How closely do you track snapshots? Do you make snapshots of your own? Does it make sense to fold what you've done into the master GDB sources and maintain them there? I use GDB user defined functions extensively, but the limitations of the existing command language has made scripts more complicated than they should be. I spent some time last month downloading GUILE with a goal of first augmenting the existing command language, then later replacing it, and finally replacing some of the C code with scripted commands. My first idea was to link the interpreter with GDB, have it source a initialization script, and create a command that gets the intepreter to eval an expression. At first, the GDB and interpreter would not know much about the other 'side', but that would be augmented over time. Unfortunately, when I downloaded GUILE, it wasn't immediately obvious where to begin. For an extension language, it seems to have a high barier to entry. --jtc -- J.T. Conklin RedBack Networks >From george@moberg.com Tue Aug 31 11:07:00 1999 From: "George T. Talbot" To: gdb@sourceware.cygnus.com Subject: dlopen() and GDB? Date: Tue, 31 Aug 1999 11:07:00 -0000 Message-id: <37CC1B5E.8E96EE4@moberg.com> X-SW-Source: 1999-q3/msg00263.html Content-length: 819 I'm writing a program using dlopen() to load in modules for various tasks. I'm having some trouble with debugging the program with GDB (linux x86, gcc 2.95.1, glibc 2.1.1pre2, gdb 4.17 w/thread support). I've been trying to use the 'add-symbol-file ' command to tell GDB where the dlopen()'d object is in memory, but I can't seem to get it right. I've tried passing the address returned in the dli_fbase field of the Dlinfo structure returned by a call to dladdr() on the entry point of my library. That didn't work, nor did adding the offset to the .rel_text section of the object to the dli_fbase address. I'm stuck. What address do I need to pass to add-symbol-file? Thanks for your help. -- George T. Talbot P.S. I read the archives and couldn't find anything about this. >From martin@home-of-linux.org Tue Aug 31 12:53:00 1999 From: Martin Baulig To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: AW: libGDB architecture Date: Tue, 31 Aug 1999 12:53:00 -0000 Message-id: X-SW-Source: 1999-q3/msg00264.html Content-length: 2159 [Outgoing mail bounced due a local mailer problem ... trying to resent from another host ... sorry if anyone gets this twice] jtc@redback.com (J.T. Conklin) writes: > Can you tell me a bit more about your GUILE interface project? How > closely do you track snapshots? Do you make snapshots of your own? > Does it make sense to fold what you've done into the master GDB > sources and maintain them there? Well, I did not make any snapshots yet (btw. how are they done? Running `make dist' tells me to look at some etc/ directory but I did not find anything useful there ... ?). The code is in module gdb-guile in the GNOME CVS Tree (you can for instance use the web interface at http://cvs.gnome.org/lxr/source/gdb-guile/ to browse it or look at http://developer.gnome.org/tools/cvs.html ). It was my plan to have my work merged into the master GDB sources sometime in future and maintain it there. > I use GDB user defined functions extensively, but the limitations of > the existing command language has made scripts more complicated than > they should be. I spent some time last month downloading GUILE with > a goal of first augmenting the existing command language, then later > replacing it, and finally replacing some of the C code with scripted > commands. > > My first idea was to link the interpreter with GDB, have it source a > initialization script, and create a command that gets the intepreter > to eval an expression. At first, the GDB and interpreter would not > know much about the other 'side', but that would be augmented over > time. Unfortunately, when I downloaded GUILE, it wasn't immediately > obvious where to begin. For an extension language, it seems to have > a high barier to entry. Currently, I added some commands to gdb: guile shell - Starts a guile interpreter guile eval - Evals rest of line as expression guile file - Evals a file Also it takes an additional command line argument so you can for instance say gdb-guile -n --batch --guile-eval \ '(use-modules (gdb corba)) (gdb-corba-main)' to start up the corba server. -- Martin Baulig - martin@home-of-linux.org - http://www.home-of-linux.org