Re: GDB Manual

Re: GDB Manual

[Jayesh Kamdar]

Where can I get that manual from or is it part of the tar file ?

Thanks,
Jayesh

Brendan Simon wrote:

> Stan Shebs wrote:
>
> > 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.
>
> > Also, feel free to comment on important user info I left out.  In
> > general, the manual should mostly focus on that which is permanently
> > true, as opposed to quirks of a particular release, which should go
> > into the README.
>
> Yep.
>
> > Next steps: replace the tutorial example with something more useful
> > than a no-longer-available version of m4, document obscure commands
> > that are missing from the manual, and merge in agentexpr.texi.
>
> Good.

Re: GDB Manual

[Stan Shebs]

   Date: Tue, 31 Aug 1999 09:15:36 +1000
   From: Brendan Simon <brendan@dgs.monash.edu.au>

   > 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 <shebs@cygnus.com>
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 <jkamdar@emc.com>

   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 <kevinb@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
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> <shebs@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 <shebs@cygnus.com>
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 <kevinb@cygnus.com>

   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 <jsm@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Stan Shebs <shebs@cygnus.com>, 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> <shebs@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 <ac131313@cygnus.com>
To: Martin Baulig <martin@home-of-linux.org>
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 <tromey@cygnus.com>
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 <ac131313@cygnus.com>
To: Todd Whitesel <toddpw@wrs.com>
Cc: GDB Developers <gdb@sourceware.cygnus.com>
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 <ac131313@cygnus.com>
To: Martin Baulig <martin@home-of-linux.org>
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 <tromey@cygnus.com> 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" <law@cygnus.com>
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 <tromey@cygnus.com> 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 <ac131313@cygnus.com>
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" <MartinB2@deutschepost.de>
To: Martin Baulig <martin@home-of-linux.org>, "'Andrew Cagney'" <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: AW: libGDB architecture - Guile interface #2
Date: Tue, 31 Aug 1999 01:09:00 -0000
Message-id: <B0000307134@ddaap077.deutschepost.de>
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" <MartinB2@deutschepost.de>
To: "'Andrew Cagney'" <ac131313@cygnus.com>, "'gdb@sourceware.cygnus.com'" <gdb@sourceware.cygnus.com>
Subject: AW: libGDB architecture
Date: Tue, 31 Aug 1999 01:12:00 -0000
Message-id: <B0000307205@ddaap077.deutschepost.de>
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'" <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: <B0000307205@ddaap077.deutschepost.de>
X-SW-Source: 1999-q3/msg00262.html
Content-length: 1314

>>>>> "Martin" == Baulig, ITS P A800, TR <MartinB2@deutschepost.de> 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" <george@moberg.com>
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 <file> <addr>' 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
<george@moberg.com>

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 <martin@home-of-linux.org>
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: <Pine.LNX.3.96.990831215030.4773A-100000@infcip52.uni-trier.de>
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