Re: problem with chained if statements?

Re: problem with chained if statements?

[Stan Shebs]

   From: jtc@redback.com (J.T. Conklin)
   Date: 16 Mar 1999 14:51:21 -0800

   I'm trying to write some user-defined commands to traverse and/or
   pretty-print some of the internal data structures used in our SW.  In
   the absense of a `switch' statement, I am using a chain of if .. else
   if ... else if ... else ... end statements.  Unfortunately it doesn't
   seem to work.

Try:

	   if ($status == $TASK_READY)
		   printf "READY    "
	   else
		if ($status == $TASK_DELAY)
		   printf "DELAY    "
	   else
		if ($status == ($TASK_DELAY | $TASK_SUSPEND))
		   printf "DELAY+S  "

I think the else and the if each need to be on their own lines.

								Stan

Re: problem with chained if statements?

[J.T. Conklin]

jtc> I'm trying to write some user-defined commands to traverse
jtc> and/or pretty-print some of the internal data structures used in
jtc> our SW.  In the absense of a `switch' statement, I am using a
jtc> chain of if .. else if ... else if ... else ... end statements.
jtc> Unfortunately it doesn't seem to work.

Stan> Try:
Stan> 	   if ($status == $TASK_READY)
Stan> 		   printf "READY    "
Stan> 	   else
Stan> 		if ($status == $TASK_DELAY)
Stan> 		   printf "DELAY    "
Stan> 	   else
Stan> 		if ($status == ($TASK_DELAY | $TASK_SUSPEND))
Stan> 		   printf "DELAY+S  "
Stan> I think the else and the if each need to be on their own lines.

It turns out to be something like:

	if ($status == $TASK_READY)
		printf "READY    "
 	else
		if ($status == $TASK_DELAY)
			printf "DELAY    "
		else
	 		if ($status == ($TASK_DELAY | $TASK_SUSPEND))
				printf "DELAY+S  "
			else
				....
			end
		end
	end

Pretty ugly (IMO).  It will suffice as a workaround, but I'll have to
look into how difficult adding "true" else-if support will be.  Would
an `elif' keyword be objectionable?  What are the current thoughts
wrt. adding a more capable extension language for gdb scripting?

	--jtc

-- 
J.T. Conklin
RedBack Networks

Re: problem with chained if statements?

[Stan Shebs]

   From: jtc@redback.com (J.T. Conklin)
   Date: 17 Mar 1999 15:51:30 -0800

   Pretty ugly (IMO).  It will suffice as a workaround, but I'll have to
   look into how difficult adding "true" else-if support will be.  Would
   an `elif' keyword be objectionable?

Sounds reasonable me.  It fits in with GDB's one-word command structure.
Stan the old Lisper has a tiny preference for "else-if" as the name of the
command...

   What are the current thoughts
   wrt. adding a more capable extension language for gdb scripting?

No consensus.  The tclites push for tcl of course, but that has
political problems. Guile would be officially approved of, but no
actual hacker seems to care enough to contribute actual changes.
Other ideas surface from time to time, but haven't really gone
anywhere.  If I was told I could have only one, I would probably
go with Guile.

							Stan

problem with chained if statements?

[J.T. Conklin]

I'm trying to write some user-defined commands to traverse and/or
pretty-print some of the internal data structures used in our SW.  In
the absense of a `switch' statement, I am using a chain of if .. else
if ... else if ... else ... end statements.  Unfortunately it doesn't
seem to work.

For example, with the chain:
	if ($status == $TASK_READY)
                printf "READY    "
        else if ($status == $TASK_DELAY)
                printf "DELAY    "
        else if ($status == ($TASK_DELAY | $TASK_SUSPEND))
                printf "DELAY+S  "
        else if ($status == $TASK_PEND)
                printf "PEND     "
        else if ($status == ($TASK_PEND | $TASK_DELAY))
                printf "PEND+T   "
        else if ($status == ($TASK_PEND | $TASK_SUSPEND))
                printf "PEND+S   "
        else if ($status == $TASK_SUSPEND)
                printf "SUSPEND  "
        else if ($status == $TASK_DEAD)
                printf "DEAD     "
        else
                printf "%8x ", $status
	end

Always prints the numeric value of $status, even when it is equal to
one of the pre-defined $TASK_FOO variables.  However, a simple test

	set $status = $TASK_READY
	if $status == $TASK_READY
		printf "OK\n"
	end
works as expected.


Is my syntax for this wrong in some way, or should I be looking for 
an bug inside GDB.

	--jtc

-- 
J.T. Conklin
RedBack Networks

Re: problem with chained if statements?

[Ovidiu Predescu]

On Thu, 18 Mar 1999 15:51:12 -0600, "Thompson, James C" 
<James.C.Thompson@USAHQ.UnitedSpaceAlliance.com> wrote:

> > From: Stan Shebs [ mailto:shebs@cygnus.com ]
> > No consensus.  The tclites push for tcl of course, but that has
> > political problems. Guile would be officially approved of, but no
> > actual hacker seems to care enough to contribute actual changes.
> > Other ideas surface from time to time, but haven't really gone
> > anywhere.  If I was told I could have only one, I would probably
> > go with Guile.
> 
> I recently added guile scripting support to a simulator project I work on,
> and found it fairly easy; we added simple (usually) guile wrappers to each
> function that needed to be available as a guile call.  If the gdb command
> parser is structured so that each major command -- print, where, next, etc.
> -- is bound to a single C function, then adding guile should be
> straightforward.  Of course, you probably wouldn't want to completely
> supplant the current command parser, but to augment it so that the current
> command syntax is still available, with "guile-looking" commands getting
> passed off to guile for evaluation.  This is certainly possible.
> 
> But I think the real power would be to add hooks into gdb at various places
> to which guile scripts can be attached.  Breakpoints, for example: if I
> could tell gdb to run a guile script each time a breakpoint is encountered,
> then I could do "conditional debugging" by letting the script examine the
> inferior program state so that execution pauses only when certain criteria
> are met.  Of course, it's possible to accomplish the same thing by building
> special debug code into the executable, but that's invasive and
> time-consuming -- best case, I have to recompile my program.  The ability to
> set up and change these hooks on the fly would be very nice.
> 
> --JT

Even more interesting would be to add support for more than one scripting
language. This could be achieved very easy with SWIG ( http://www.swig.org ).
This is a free software tool (has a BSD license) that makes easy adding
scripting support to C programs. All you have to do is to write an interface
file describing your internal C functions. SWIG is a compiler that takes this
interface file and generates the glue functions that are could be used directly
from various interpreters, including Perl, Python, TCL and Guile. The only
thing now is to see how to integrate it with the current command line
processing code.

I think such a thing could satisfy most of the people since they will not be
forced to use a scripting language or another to write their extension. One
question though: would its license allow FSF to release the resulting C code
under GPL? Would FSF be happy if gdb suddenly becomes dependent on a tool
that's not owned by them?

Greetings,
Ovidiu

RE: problem with chained if statements?

[Thompson, James C]

> From: Stan Shebs [ mailto:shebs@cygnus.com ]
> No consensus.  The tclites push for tcl of course, but that has
> political problems. Guile would be officially approved of, but no
> actual hacker seems to care enough to contribute actual changes.
> Other ideas surface from time to time, but haven't really gone
> anywhere.  If I was told I could have only one, I would probably
> go with Guile.

I recently added guile scripting support to a simulator project I work on,
and found it fairly easy; we added simple (usually) guile wrappers to each
function that needed to be available as a guile call.  If the gdb command
parser is structured so that each major command -- print, where, next, etc.
-- is bound to a single C function, then adding guile should be
straightforward.  Of course, you probably wouldn't want to completely
supplant the current command parser, but to augment it so that the current
command syntax is still available, with "guile-looking" commands getting
passed off to guile for evaluation.  This is certainly possible.

But I think the real power would be to add hooks into gdb at various places
to which guile scripts can be attached.  Breakpoints, for example: if I
could tell gdb to run a guile script each time a breakpoint is encountered,
then I could do "conditional debugging" by letting the script examine the
inferior program state so that execution pauses only when certain criteria
are met.  Of course, it's possible to accomplish the same thing by building
special debug code into the executable, but that's invasive and
time-consuming -- best case, I have to recompile my program.  The ability to
set up and change these hooks on the fly would be very nice.

--JT
From shebs@cygnus.com Thu Apr 01 00:00:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: Guenther.Grau@bk.bosch.de
Cc: gdb@cygnus.com
Subject: Re: gdb-19990209 on sparc-2.5.1
Date: Thu, 01 Apr 1999 00:00:00 -0000
Message-id: <199903252355.PAA05700@andros.cygnus.com>
References: <36FABAB8.24A9B865@bk.bosch.de>
X-SW-Source: 1999-q1/msg00169.html
Content-length: 1027

   Date: Thu, 25 Mar 1999 23:37:44 +0100
   From: Guenther Grau <Guenther.Grau@bk.bosch.de>

   Stan Shebs wrote:
   > No.  4.17.86 is similar to 19990209, but comes from a branch that was
   > sprouted from the trunk on 15 Feb, and includes a bunch of little
   > fixes that were done as part of the pre-release testing process.
   > 19990209 is derived from the repository trunk by whacking out
   > Cygnus-only bits.  You should see fewer problems with 4.17.86.
   [...]
   > Try 4.17.86 instead - I remember something about a configuration
   > problem in opcodes in a snapshot, that might be the one.

   Ok. I did that, and it does indeed build properly. The warnings
   are still there, though. Do you accept any patches fixing the
   warnings? 

Sure, but not for 4.18, it's time to get it into users' hands.

Fortunately, this isn't going to be the last GDB release ever :-), so
it's still worthwhile to make all the warnings go away.  Andrew C.
has been bashing many of them, but there are lots left...

							Stan

Re: problem with chained if statements?

[Stan Shebs]

   Date: Thu, 18 Mar 1999 15:02:49 -0800
   From: Ovidiu Predescu <ovidiu@cup.hp.com>

   Even more interesting would be to add support for more than one scripting
   language. This could be achieved very easy with SWIG ( http://www.swig.org ).
   [...]

SWIG is certainly an interesting approach, worth thinking about further.

   I think such a thing could satisfy most of the people since they will not be
   forced to use a scripting language or another to write their extension. One
   question though: would its license allow FSF to release the resulting C code
   under GPL?

That's somewhat of a gray area.  It's usually a good idea for any program
generating tool to include some sort of special provision for the generated
code, such as the terms for the skeleton parser in bison.  I didn't see
anything like that in the SWIG info though.

   Would FSF be happy if gdb suddenly becomes dependent on a tool
   that's not owned by them?

Well, the "FSF" for this issue only consists of RMS, and everybody on
this mailing list.  My own inclination is to be very careful about
adding dependencies of any sort, irrespective of tool ownership,
because that's just good engineering.

To take an example from GCC, the perfect hash table that GCC uses to
look up keywords is generated by a program called gperf.  Gperf is in
C++ (or was anyway), and back in 1989, that meant g++ 1.x.  I was
working on the Mac port of GCC, and the Mac API included several new
keywords, which meant tweaking GCC's hash table.  The hardest part of
this task was getting g++ to build a working gperf!  Fortunately, I
only had to do this the one time; it would have been a big timesink
if I'd had to do that much fiddling every time GCC got changed.

So to get back to SWIG, if its output became intertwined with GDB, we
would have to start shipping SWIG with every release and snapshot of
GDB, we would probably want to have it running on all of GDB's hosts,
work it into build processes (though perhaps for maintainers only), etc.
However, it's not clear to me that it has to be so interconnected;
I can see where GDB would be SWIG-friendly without having it be in the
critical path.  That seems to me like better engineering for this kind
of extension.

								Stan

RE: problem with chained if statements?

[Thompson, James C]

> -----Original Message-----
> Um, gdb already lets you do this, subject to the limitations 
> of the gdb
> command language and variable facilities.

I guess I've only been using the basic gdb commands, as I'm not familiar
with "command" (and on further investigation it sounds like what I need is
more akin to "condition" than "command").  The point is that if you have a
true scripting language like guile then you're not subject to the
limitations you mentioned.  And it sounds like some of the hooks are already
in place.

--JT

Re: problem with chained if statements?

[Todd Whitesel]

> But I think the real power would be to add hooks into gdb at various places
> to which guile scripts can be attached.  Breakpoints, for example: if I
> could tell gdb to run a guile script each time a breakpoint is encountered,
> then I could do "conditional debugging" by letting the script examine the
> inferior program state so that execution pauses only when certain criteria
> are met.  Of course, it's possible to accomplish the same thing by building
> special debug code into the executable, but that's invasive and
> time-consuming -- best case, I have to recompile my program.  The ability to
> set up and change these hooks on the fly would be very nice.

Um, gdb already lets you do this, subject to the limitations of the gdb
command language and variable facilities.

(gdb) help command
Set commands to be executed when a breakpoint is hit.
Give breakpoint number as argument after "commands".
With no argument, the targeted breakpoint is the last one set.
The commands themselves follow starting on the next line.
Type a line containing "end" to indicate the end of them.
Give "silent" as the first line to make the breakpoint silent;
then no output is printed when it is hit, except what the commands print.

-- 
Todd Whitesel
toddpw @ wrs.com