Re: Proposal: convert function definitions to prototyped form

[Kevin Buettner <kevinb@cygnus.com>]

On Jun 13, 11:09am, Andrew Cagney wrote:

> Kevin Buettner wrote:
> > 
> > As many of you know, I'm in the midst of purging the use of ``PARAMS''
> > in prototyped function declarations from the gdb sources.  After this
> > activity is concluded, I'd like to begin converting function
> > definitions whose parameters are declared using the traditional C
> > style to the ISO C prototyped form.  I.e, I'd like to convert
> > functions of the form
> 
> Kevin,
> 
> Would a fair summary of this be that you've encountered the following
> road blocks:
> 
> 	o	indent.pro
> 
> 		So that indent gives better results

I don't think this is a serious road block.  While it would be nice to
be able to specify an indent.pro file (e.g., "indent --options-file
gdbtypes.pro"), it's not absolutely necessary for the task at hand.

As I noted in my reply to Eric, I already know the complete list of
types which indent has to know about in order to complete the
protoization task.  It is easy to put this list in the script which
does the conversion.  I.e,

	@typelist = qw(ADDR32 B_TYPE ... value_ptr xdrproc_t);
	$indentoptions = '-T ' . join(' -T ', @typelist);

> 	o	a drain of some of the backlog of
> 		patches (pascal I believe is now
> 		going in).
> 
> 		Apple and HP?

I think the patch backlog is the real road block.

However, even for this road block, the only reason for delaying the
protoization activity is to make it easier on the people doing the
patch integration.  Perhaps setting a date for the protoization
activity would help motivate the patch integrators to clear some of
the backlog?

> No one has objected to the principal (well not on gdb-patches :-) and
> the tool would be based on perl rather than the the gcc thing.
> 
> Once those blockages are cleared, it can be scheduled and can go
> through?

I still have a little over a week to go on the PARAMS elimination
activity, so any time after then is good for me.  How does midnight
GMT of Sunday July 9 sound?  That's about four weeks away.  Is that
enough time for the patch integrators to clear the patch backlog?
From eliz@delorie.com Tue Jun 13 03:34:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: ebachalo@redhat.com
Cc: jtc@redback.com, kevinb@cygnus.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com
Subject: Re: Proposal: convert function definitions to prototyped form
Date: Tue, 13 Jun 2000 03:34:00 -0000
Message-id: <200006131034.GAA25579@indy.delorie.com>
References: <1000602075018.ZM29997@ocotillo.lan> <200006021226.e52CQ2I01239@delius.kettenis.local> <1000602151553.ZM30578@ocotillo.lan> <5mya4om115.fsf@jtc.redback.com> <394572A4.EF8646F2@redhat.com>
X-SW-Source: 2000-06/msg00117.html
Content-length: 209

> Date: Mon, 12 Jun 2000 16:30:44 -0700
> From: Eric Bachalo <ebachalo@redhat.com>
>
> Not sure how ported etags and python are for all the hosts that
> compile GDB though.

What platforms cause your concern?
From dcroyle@telerama.com Tue Jun 13 09:06:00 2000
From: David J Croyle <dcroyle@telerama.com>
To: gdb@sourceware.cygnus.com
Subject: Using GDB with standalone assembly code questions
Date: Tue, 13 Jun 2000 09:06:00 -0000
Message-id: <39466A96.E7B022BD@telerama.com>
X-SW-Source: 2000-06/msg00118.html
Content-length: 3164

Hello all!

We are trying to debug/verify a very simple ARM assembly language
program
and we hoped to use the gdb ARM simulator w/ddd as the frontend though
we
have encountered a few issues.

Our goal is to single step through the code and watch the registers
change
(and perhaps observe memory locations/memory mapped registers) but gdb
seems some what intent on not simulating our code.

We use the following sequence to "get gdb going":

(Load an ARM executable into gdb via DDD Open Program under File):

(gdb) file testarmasm.exec
warning: arm architecture file may be incompatible with armv4 target.
Reading symbols from
testarmasm.exec
(no debugging symbols found)...done.

We then issued these commands to gdb by hand:

(gdb) target sim
Connected to the simulator.
(gdb) set language asm
(gdb) load
Loading section .text, size 0x124 vma 0x0
Start address 0x0
Transfer rate: 2336 bits in <1 sec.

However when we issue the step command the response is:

(gdb) step
Single stepping until exit from function _start, 
which has no line number information.
The program is not being run

Our registers don't change and neither does the program counter.

When we issue "run" gdb seems to get stuck in a never ending loop (the
registers which we have told ddd to display do not change) and the green
light just keeps blinking.

If we interrupt gdb and start the whole process over (reload the
executable, issue target sim, etc.) and use the "go" command and specify
a
label from our code such as ledon23(a valid label) our response is:

(gdb) go ledon23
Breakpoint 1 at 0xa8
Continuing at 0xa8.
The program is not being run.
(gdb) 

We then see the program counter pointing to 0xa8 but issuing "run"
either
locks gdb or if we stop the run almost imediatly with control-c, we can
see that a few registers changed though the run/interruption cannot be
done with any hopes of reliability. 

It is interesting to note that while gdb mentions it did not find any
debug symbols, it does know of the labels we used in our ASM program
meaning it has read that information successfully from our executable.

In addition to the run/control-c, we can issue a "b <label>" and gdb
will
set the breakpoint at the correct label (the address was verified by
looking out our .lst file). However we still do not have the ability to
single step/step into the next instruction.

An "info watchpoints" shows all our breakpoints with the correct labels.

Are there any suggestions on how we can single step through our code or
execute our "pure ASM" program and observe registers and such?

We've built gdb for target=strongarm-elf on a i686-pc-linux-gnu host.
We've told ddd to use our strongarm built gdb by using the --debugger
switch on ddd start-up.

Our ARM executable was built on this same machine, cross-compiled by
using
a cross toolchain we built to produce standalone ARM executables (we
used
newlib headers instead of glibc but since this is "pure ASM" program
that
should not matter).

Thanks in advance, 
Dave & Vasant.





David J. Croyle
EE / Software Developer
Foerster Instruments, Inc.
Windows e-mail: dcroyle@foerstergroup.com
  Linux e-mail: dcroyle@telerama.com
From fnasser@cygnus.com Tue Jun 13 10:02:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: David J Croyle <dcroyle@telerama.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Using GDB with standalone assembly code questions
Date: Tue, 13 Jun 2000 10:02:00 -0000
Message-id: <394668A0.7C8B3DA2@cygnus.com>
References: <39466A96.E7B022BD@telerama.com>
X-SW-Source: 2000-06/msg00119.html
Content-length: 3829

David,

First of all, which compiler and which version of it have you used?
The exact compile line, with all switches is also necessary.

Then you should tell us which gdb (version, where did you get it etc.)
you are using.

Fernando


David J Croyle wrote:
> 
> Hello all!
> 
> We are trying to debug/verify a very simple ARM assembly language
> program
> and we hoped to use the gdb ARM simulator w/ddd as the frontend though
> we
> have encountered a few issues.
> 
> Our goal is to single step through the code and watch the registers
> change
> (and perhaps observe memory locations/memory mapped registers) but gdb
> seems some what intent on not simulating our code.
> 
> We use the following sequence to "get gdb going":
> 
> (Load an ARM executable into gdb via DDD Open Program under File):
> 
> (gdb) file testarmasm.exec
> warning: arm architecture file may be incompatible with armv4 target.
> Reading symbols from
> testarmasm.exec
> (no debugging symbols found)...done.
> 
> We then issued these commands to gdb by hand:
> 
> (gdb) target sim
> Connected to the simulator.
> (gdb) set language asm
> (gdb) load
> Loading section .text, size 0x124 vma 0x0
> Start address 0x0
> Transfer rate: 2336 bits in <1 sec.
> 
> However when we issue the step command the response is:
> 
> (gdb) step
> Single stepping until exit from function _start,
> which has no line number information.
> The program is not being run
> 
> Our registers don't change and neither does the program counter.
> 
> When we issue "run" gdb seems to get stuck in a never ending loop (the
> registers which we have told ddd to display do not change) and the green
> light just keeps blinking.
> 
> If we interrupt gdb and start the whole process over (reload the
> executable, issue target sim, etc.) and use the "go" command and specify
> a
> label from our code such as ledon23(a valid label) our response is:
> 
> (gdb) go ledon23
> Breakpoint 1 at 0xa8
> Continuing at 0xa8.
> The program is not being run.
> (gdb)
> 
> We then see the program counter pointing to 0xa8 but issuing "run"
> either
> locks gdb or if we stop the run almost imediatly with control-c, we can
> see that a few registers changed though the run/interruption cannot be
> done with any hopes of reliability.
> 
> It is interesting to note that while gdb mentions it did not find any
> debug symbols, it does know of the labels we used in our ASM program
> meaning it has read that information successfully from our executable.
> 
> In addition to the run/control-c, we can issue a "b <label>" and gdb
> will
> set the breakpoint at the correct label (the address was verified by
> looking out our .lst file). However we still do not have the ability to
> single step/step into the next instruction.
> 
> An "info watchpoints" shows all our breakpoints with the correct labels.
> 
> Are there any suggestions on how we can single step through our code or
> execute our "pure ASM" program and observe registers and such?
> 
> We've built gdb for target=strongarm-elf on a i686-pc-linux-gnu host.
> We've told ddd to use our strongarm built gdb by using the --debugger
> switch on ddd start-up.
> 
> Our ARM executable was built on this same machine, cross-compiled by
> using
> a cross toolchain we built to produce standalone ARM executables (we
> used
> newlib headers instead of glibc but since this is "pure ASM" program
> that
> should not matter).
> 
> Thanks in advance,
> Dave & Vasant.
> 
> David J. Croyle
> EE / Software Developer
> Foerster Instruments, Inc.
> Windows e-mail: dcroyle@foerstergroup.com
>   Linux e-mail: dcroyle@telerama.com

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From jtc@redback.com Tue Jun 13 15:19:00 2000
From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: nindy protocol 
Date: Tue, 13 Jun 2000 15:19:00 -0000
Message-id: <5mbt155ino.fsf@jtc.redback.com>
X-SW-Source: 2000-06/msg00120.html
Content-length: 1697

Does anyone have a copy of the Nindy protocol specification or an old
Intel gnu960 (aka CTOOLS) distribution that contains Nindy source?  I
checked developer.intel.com, but the CTOOLS distributions currently
available all have mon960 instead of Nindy.

The reason I ask is because I'd like to get rid of the dcache_fetch()
and dcache_poke() functions which are only used by remote-nindy.c and
remote-bug.c.  

Unlike most remote targets, the nindy_xfer_inferior_memory() function
breaks the transfer into multiple word-aligned word-sized transfers.
These word-sized transfers are performed through dcache_fetch() and
dcache_poke().  The header comment for nindy_xfer_inferior_memory()
states:
        "This is stolen almost directly from infptrace.c's
        child_xfer_memory, which also deals with a word-oriented
        memory interface.  Sometime, FIXME, rewrite this to not use
        the word-oriented routines."

I'm not sure whether this means that nindy protocol supports non-word-
aligned, non-word-sized transfers, and the code just needs to be fixed
to use them, or if something more substantial must be done.  I checked
the code in nindy-share/nindy.c, which seems to indicate that the
protocol supports arbitrary sized/aligned transfers, but it's not 
explicitly stated.  I'd like to confirm this before submitting a patch.

In case anyones wondering, the primary reason I'd like to get rid of
these functions is that otherwise I'd have to adapt them to take a
mem_attrib parameter.  They also seem to be poorly specified.  They
read and write a host word, when I'd think they would be defined in
terms of the target's word size.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@apple.com Tue Jun 13 16:25:00 2000
From: Stan Shebs <shebs@apple.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: nindy protocol
Date: Tue, 13 Jun 2000 16:25:00 -0000
Message-id: <3946C259.3F4C058A@apple.com>
References: <5mbt155ino.fsf@jtc.redback.com>
X-SW-Source: 2000-06/msg00121.html
Content-length: 1124

"J.T. Conklin" wrote:
> 
> Does anyone have a copy of the Nindy protocol specification or an old
> Intel gnu960 (aka CTOOLS) distribution that contains Nindy source?  I
> checked developer.intel.com, but the CTOOLS distributions currently
> available all have mon960 instead of Nindy.

I squirreled away a couple copies of CTOOLs when I was at Cygnus, but
I don't know if any were old enough to include Nindy sources still;
don't remember ever seeing actual Nindy sources.

> The reason I ask is because I'd like to get rid of the dcache_fetch()
> and dcache_poke() functions which are only used by remote-nindy.c and
> remote-bug.c.

IMHO we should officially declare Nindy support obsolete.  As you observed,
Intel now denies its existence :-), the last physical board I knew of
(at Cygnus) died ca 1996, and the last couple of years of GDB churning
probably broke the Nindy support, but nobody appears to have noticed,
or cared enough to report it as a bug.

I could do the research to justify obsoleting Nindy, then you'd be free
to whack the dcache functions (remote-bug.c is also an obsoletion
possibility BTW).

Stan
From ac131313@cygnus.com Tue Jun 13 18:32:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: David J Croyle <dcroyle@telerama.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Using GDB with standalone assembly code questions
Date: Tue, 13 Jun 2000 18:32:00 -0000
Message-id: <3946E059.266C39A3@cygnus.com>
References: <39466A96.E7B022BD@telerama.com>
X-SW-Source: 2000-06/msg00122.html
Content-length: 339

David J Croyle wrote:


> (gdb) step
> Single stepping until exit from function _start,
> which has no line number information.
> The program is not being run


FYI, several things to be careful about.

Use stepi not step.

You may need to do a:

	(gdb) break *_start
or is that break *&_start?
	(gdb) run

to get things started.

	Andrew
From jtc@redback.com Tue Jun 13 18:54:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Stan Shebs <shebs@apple.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: nindy protocol
Date: Tue, 13 Jun 2000 18:54:00 -0000
Message-id: <5mg0qh3u4o.fsf@jtc.redback.com>
References: <5mbt155ino.fsf@jtc.redback.com> <3946C259.3F4C058A@apple.com>
X-SW-Source: 2000-06/msg00123.html
Content-length: 2235

>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:
Stan> I squirreled away a couple copies of CTOOLs when I was at Cygnus, but
Stan> I don't know if any were old enough to include Nindy sources still;
Stan> don't remember ever seeing actual Nindy sources.

Do you still have access to them?  I found the CTOOLS 5.0 release
notes on developer.intel.com --- it looks like Nindy was replaced
then.  If you have an earlier release, it should have the Nindy
sources.

>> The reason I ask is because I'd like to get rid of the dcache_fetch()
>> and dcache_poke() functions which are only used by remote-nindy.c and
>> remote-bug.c.

Stan> IMHO we should officially declare Nindy support obsolete.  As
Stan> you observed, Intel now denies its existence :-), the last
Stan> physical board I knew of (at Cygnus) died ca 1996, and the last
Stan> couple of years of GDB churning probably broke the Nindy
Stan> support, but nobody appears to have noticed, or cared enough to
Stan> report it as a bug.

Stan> I could do the research to justify obsoleting Nindy, then you'd
Stan> be free to whack the dcache functions (remote-bug.c is also an
Stan> obsoletion possibility BTW).

Feel free.  I'm not going to argue against it.  However, if Nindy
supports arbitrary sized and aligned memory transfers the changes
necessary to remove dcache_fetch() and dcache_poke() are trivial.  If
we can't determine whether it's safe, and you want to wait more before
obsoleting the config, I propose that we commit it anyway.  If it
breaks anything and anyone cares, we'll hear about it soon enough.

It appears that the remote-bug.c implements read/write by downloading
and uploading s-records, so there should be no problems at all removing
dcache_fetch() and dcache_poke() from it (at least I've never heard of
any srec reader that didn't support arbitrary addresses).

If the MVME187BUG monitor is anything like the m68k, ppc, and coldfire
versions of BUG, it could be rewritten to use the generic monitor code,
resulting in a smaller and more robust target.  Whether anyone cares to
do so is another story.  If remote-bug.c is obsoleted, it appears that
most of remote-utils.c (all the gr_* stuff) can too.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From shebs@apple.com Tue Jun 13 20:20:00 2000
From: Stan Shebs <shebs@apple.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: nindy protocol
Date: Tue, 13 Jun 2000 20:20:00 -0000
Message-id: <3946F992.4A40BA12@apple.com>
References: <5mbt155ino.fsf@jtc.redback.com> <3946C259.3F4C058A@apple.com> <5mg0qh3u4o.fsf@jtc.redback.com>
X-SW-Source: 2000-06/msg00124.html
Content-length: 1822

"J.T. Conklin" wrote:
> 
> >>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:
> Stan> I squirreled away a couple copies of CTOOLs when I was at Cygnus, but
> Stan> I don't know if any were old enough to include Nindy sources still;
> Stan> don't remember ever seeing actual Nindy sources.
> 
> Do you still have access to them?  I found the CTOOLS 5.0 release
> notes on developer.intel.com --- it looks like Nindy was replaced
> then.  If you have an earlier release, it should have the Nindy
> sources.

Actually, I think 5.0 is the earliest I have too.

> Stan> I could do the research to justify obsoleting Nindy, then you'd
> Stan> be free to whack the dcache functions (remote-bug.c is also an
> Stan> obsoletion possibility BTW).
> 
> Feel free.  I'm not going to argue against it.  However, if Nindy
> supports arbitrary sized and aligned memory transfers the changes
> necessary to remove dcache_fetch() and dcache_poke() are trivial.  If
> we can't determine whether it's safe, and you want to wait more before
> obsoleting the config, I propose that we commit it anyway.  If it
> breaks anything and anyone cares, we'll hear about it soon enough.

Fine by me.

> If the MVME187BUG monitor is anything like the m68k, ppc, and coldfire
> versions of BUG, it could be rewritten to use the generic monitor code,
> resulting in a smaller and more robust target.  Whether anyone cares to
> do so is another story.

There was at least one m88k workstation alive recently, somebody on this
whose name I forget (sorry) sent in some patches for it last year or so.
But embedded m88k boards these days?  Rather unlikely I think.

> If remote-bug.c is obsoleted, it appears that
> most of remote-utils.c (all the gr_* stuff) can too.

Yup, an attractive side benefit.  To borrow from S&W, "omit needless code". :-)

Stan
From qqi@world.std.com Wed Jun 14 05:50:00 2000
From: Quality Quorum <qqi@world.std.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: Re: That vision thing ...
Date: Wed, 14 Jun 2000 05:50:00 -0000
Message-id: <Pine.SGI.3.95.1000614084827.13939A-100000@world.std.com>
References: <39457E1A.D22C6468@cygnus.com>
X-SW-Source: 2000-06/msg00125.html
Content-length: 390

On Tue, 13 Jun 2000, Andrew Cagney wrote:

> So yes.
> 
> Exactly how to do this is another problem entirely.  Do we just
> re-arange the deck chairs or look more deeply.

I would say re-arranging of deck chairs will be a signficant help
in the looking, especially for the guys like me who mostly uses
gdb and seldom has to tweak pieces here and there.

> 
> 	Andrew
> 

Thanks,

Aleksey