* -Wmissing-prototypes ...
1999-11-27 18:50 -Wmissing-prototypes Andrew Cagney
@ 1999-09-20 0:46 ` Andrew Cagney
[not found] ` <37CB6DBE.2083662F@cygnus.com>
1 sibling, 0 replies; 4+ messages in thread
From: Andrew Cagney @ 1999-09-20 0:46 UTC (permalink / raw)
To: gdb
FYI,
There is now a reasonable chance that GDB can be compiled with the
-Wmissing-prototypes option. Thanks to JimI, JimB and Fernando and
Elena for various specific cleanups.
Andrew
My current list is:
--enable-build-warnings=-Werror\
,-Wimplicit\
,-Wreturn-type\
,-Wcomment\
,-Wtrigraphs\
,-Wformat\
,-Wparentheses\
,-Wpointer-arith\
,-Wmissing-prototypes\
,-Woverloaded-virtual\
From ac131313@cygnus.com Mon Sep 20 19:47:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Ovidiu Predescu <ovidiu@cup.hp.com>
Cc: Jim Blandy <jimb@cygnus.com>, Stan Shebs <shebs@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: libGDB architecture
Date: Mon, 20 Sep 1999 19:47:00 -0000
Message-id: <37E6F077.F75C8BE8@cygnus.com>
References: <199909162200.PAA21351@hercules.cup.hp.com>
X-SW-Source: 1999-q3/msg00370.html
Content-length: 3693
Ovidiu Predescu wrote:
>
> On 16 Sep 1999 14:08:39 -0500, Jim Blandy <jimb@cygnus.com> wrote:
>
> > How should we handle objects allocated on obstacks? Most of the
> > symbolic info (types; variables) is allocated this way. I don't think
> > it's practical to keep the entire obstack around until all its
> > objects' reference counts have dropped to zero.
>
> I think we should expect clients to behave nicely and not keep references to
> such objects around for an indefinite time. Once they get a message that such
> an object became invalid, the client should release its reference. Another
> approach for the client would be to copy such information in its own internal
> data structures, if they are needed for a longer time, but this shouldn't be
> the case.
To re-iterate my position, as a first pass, I strongly prefer to keep a
certain distance between GDB's internals and the client. When it comes
to performance, I can't see the access mechanisms provided for
primitives such as breakpoints and frames even appearing on the radar.
In fact, to the best of my knowledge the current biggest hot spot
(everyone keeps pointing a finger at) is the overhead/hazards of
serializing GDB's communication (via a pty say).
I think a better (safer, more likely to succeed) approach would be to,
in parallel with the introduction of a robust interface, start
investigating what have been identified as other (likely) hot spots.
Interestingly, many of the below are actually independent of the libGDB
interface:
o variable update when stepping
I believe that the GDBtk team
(who do access GDB's internals
using a more direct mechanism)
have already identified this as
a performance hot spot.
o A per thread cache.
Well actually the lack of it :-)
Here is another example of why it is
better to have the client keep a safe
distance from GDB. The last thing
we want is for clients to be locked
into the existing mechanisms.
o memory transfer / large target
data structures
In this case I think more
fundamental internal GDB changes
will be needed before you can start
thinking about providing direct access
to GDB's internal memory structures.
Perhaps HP are interested in taking on
the task of re-working GDB's local memory
cache so that a more direct interface is
possible. I kind of suspect that papers
on distributed shared memory would be
highly relevant.
While that work is in progress a slow
robust mechanism would continue to be used.
o (as always)
symbol table / name lookup
A hot topic in anyone's language :-)
> Releasing the obstacks happens usually as a result of an action triggered by
> the client, so it should be prepared to release these objects. We can document
> which are those functions in the API that deallocate entire obstacks; these
> shouldn't be that many, the only important places I can think of are associated
> with freeing of an object file and reloading of symbols.
(Stack frames are implemented using obstacks.)
I don't think it is reasonable to assume that the client is in control
:-). As GDB becomes more and more asynchronous it is just as likely that
the target will trigger events as it is the client.
Consider GDB debugging a multi-threaded target. The long term plan is
for GDB to allow some threads to run free while others are halted - in
such a situation any assumption that the client is in control has to be
thrown out the window :-).
> Either way we need the client's cooperation, which is what you require anyway
> from somebody that lives with you in the same data space ;-).
Your too trusting :-)
Andrew
PS: See Tcl_IncrRefCount and Tcl_DecrRefCount
From ac131313@cygnus.com Mon Sep 20 22:45:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: cagney@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: QUIT as a function?
Date: Mon, 20 Sep 1999 22:45:00 -0000
Message-id: <37E71AEB.B9C35E7D@cygnus.com>
References: <199909171842.LAA10740@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00371.html
Content-length: 736
Stan Shebs wrote:
>
> From: Andrew Cagney <ac131313@cygnus.com>
> Date: Fri, 17 Sep 1999 15:14:42 +1000
>
> Is there any reason for not converting QUIT into a function?
>
> Yes, QUIT appears in the inner loops of the symbol readers, which
> are known to be compute-bound and some of the most time-critical
> code in all GDB. So I'd want to see some comparative performance
> numbers, especially on hosts with lame calling conventions, before
> we go messing with QUIT.
True. I guess a pre-cursor would be to ``fix'' the symbol table stuff
so that it wasn't so dependent on linear search algorithms :-(. The
performance gains made there should more than out way any performance
loss with an extra function call.
Andrew
From jingham@leda.cygnus.com Tue Sep 21 11:31:00 1999
From: James Ingham <jingham@leda.cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: libGDB architecture
Date: Tue, 21 Sep 1999 11:31:00 -0000
Message-id: <mfn1ugceho.fsf@leda.cygnus.com>
References: <199909162200.PAA21351@hercules.cup.hp.com> <37E6F077.F75C8BE8@cygnus.com>
X-SW-Source: 1999-q3/msg00372.html
Content-length: 2073
Andrew Cagney <ac131313@cygnus.com> writes:
>
> I think a better (safer, more likely to succeed) approach would be to,
> in parallel with the introduction of a robust interface, start
> investigating what have been identified as other (likely) hot spots.
> Interestingly, many of the below are actually independent of the libGDB
> interface:
>
I agree with Andrew here. We can get a lot of benefit just breaking
down some of the atomic operations in the GDB interface into useable
bits. We have already done this with the variable interface (see
gdbtk-variable.c) Another example where you need to do this is in
the backtrace command. For most GUI purposes, you really don't want
an undifferentiated list of 100 stack elements with all their
arguments, names, types... Parsing and displaying this was very
slow. You really want one command that just gives you the list of
functions on the stack. Then a way to get the args (preferrably
already list-ified) for each level. That way you can do intelligent
things like only fetch what fits in the current window, and get the
others on scrolling or whatever...
This is just one other example. There are other places where
providing a more discrete interface into gdb would be a big benefit,
and probably reduce most of the need to get your hands on the actual
data in gdb.
I am still worried about parsing very large arrays, etc, however. For
this to be fast, you probably will have to somehow get the data
directly...
> Your too trusting :-)
>
> Andrew
>
> PS: See Tcl_IncrRefCount and Tcl_DecrRefCount
There are actually two places where Tcl does preservation of data.
One is in the Object system, which uses the calls Andrew sites above,
and one is for clients that want to hold data over a call that may
potentially free it - see Tcl_Preserve and Tcl_EventuallyFree.
Jim
--
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham jingham@cygnus.com
Cygnus Solutions Inc.
From masahiro@lsi.nec.co.jp Wed Sep 22 02:35:00 1999
From: Masahiro Fukuda <masahiro@lsi.nec.co.jp>
To: gdb@sourceware.cygnus.com
Cc: masahiro@lsi.nec.co.jp
Subject: one proposal ... `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT ??
Date: Wed, 22 Sep 1999 02:35:00 -0000
Message-id: <199909220933.SAA06550@mctcs13.ucom.lsi.nec.co.jp>
X-SW-Source: 1999-q3/msg00373.html
Content-length: 7368
Hi,
I recently realize that gdb-19990830 extends some
keyword into gdb serial protocol, and I also read
some mailing list archives.
My name is Masahiro Fukuda. Independently, I added
some keyword (actually [B/b] just like J.T.C did) into
gdb serial protocol in order to transmit "breakpoint" to
gdbserver instead of writing TRAP instruction.
Some arguements including <addr>, <length>, <ignore_count>
follow breakpiont keyword in my code. Those command packets
are generated in v850_insert_hw_breakpint()/v850_insert_watchpoint()
in v850-tdep.c.
Andrew suggested me that I would join gdb mailing list
when I wrote an e-mail to him how I should do for this
kind of proposal.
Expected typical scenario is shown below when ignore count
is transmitted to target. Suppose, there are three
breakponits/watchpoints and each has following ignore count.
number type ignore count
------------------------------------------
#1 hardware breakpoint 7
#2 read watchpoint 5
#3 write watchpoint 3
Please find the gdb/target communication below with illustration.
(a) Breakpoints/watchpoints are inserted before continue.
(b) Gdb continues target. Target decrements each ignore count
every time when target hits respective breakpoint/watchpoint
without making any communication with gdb as far as
respective ignore count does not equal to zero.
At last, target tells gdb after it hits breakpoint/watchpoint
whose ignore count equal to zero.
(c) breakpoints/watchpoints are removed after target stopps
and each current ignore count is retrieved from target.
---------------------- illustration ----------------------
gdb side -------------------- target side
(a)insert breakpoints -----------------------> (#1, 7)
before continue -----------------------> (#2, 5)
with ignore count -----------------------> (#3, 3)
(b)continue ----------------------------------->
wait for target | #1 hit (#1, 7->6)
to stop | #1 hit (#1, 6->5)
| #1 hit (#1, 5->4)
| #2 hit (#2, 5->4)
time | #3 hit (#3, 3->2)
| #1 hit (#1, 4->3)
| #1 hit (#1, 3->2)
| #1 hit (#1, 2->1)
| #2 hit (#2, 4->3)
| #3 hit (#3, 2->1)
| #1 hit (#1, 1->0)
V #1 hit (#1, 0->!)
target stop <-------------------------------
(c)remove breakponits -----------------------> (#1 )
remained ignore count returns (0) <---------
remove breakponits -----------------------> (#2 )
remained ignore count returns (3) <---------
remove breakponits -----------------------> (#3 )
remained ignore count returns (1) <---------
---------------------- illustration ----------------------
Next, please find the proposed Z/z packet.
---------------------- proposed Z/z packet ----------------------
remove `z'T`,'ADDR`,'LENGTH` `z' should retrieve
break remained IGNORE_COUNT
or from target.
watcchpoint reply `OK'IGNORE_COUNT for success
The others are the same
as current spec.
insert `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT just add IGNORE_COUNT
break The othera are the same
or as current spec.
watcchpoint
---------------------- proposed Z/Z packet ----------------------
---------------------- current Z/Z packet ----------------------
remove break or `z'T`,'ADDR`,'LENGTH See `Z'.
watchpoint *(draft)*
*(optional)*
insert break or `Z'T`,'ADDR`,'LENGTH T is type: `0' - software
watchpoint *(draft)* breakpoint, `1' - hardware
*(optional)* breakpoint, `2' - write
watchpoint, `3' - read
watchpoint, `4' - access
watchpoint; ADDR is address;
LENGTH is in bytes. For a
software breakpoint, LENGTH
specifies the size of the
instruction to be patched.
For hardware breakpoints and
watchpoints LENGTH specifies
the memory region to be
monitored.
reply `E'NN for an error
reply `OK' for success
`' If not supported.
---------------------- current Z/Z packet ----------------------
Some fragment of my code is shown below.
I will follow snapshot specification(I will modify my code to
adjust snapshot specification) such like....
B -> Z
w -> 2
r -> 3
a -> 4
---------------------- cut cut cut ----------------------
int
v850_insert_watchpoint(addr,len,type)
int addr, len, type;
{
char buf[PBUFSIZ], *p;
struct breakpoint *b, *tmp; /* breakpoint.c */
int ignore_count; /* see breakpoint.h */
value_ptr v; /* see breakpoint.h */
int watch_addr;
/* construct "Bw"<memaddr>","<len>","<ignore_count>" if type == 0 */
/* construct "Br"<memaddr>","<len>","<ignore_count>" if type == 1 */
/* construct "Ba"<memaddr>","<len>","<ignore_count>" if type == 2 */
/* sprintf (buf, "Bx%lx,%x,%x", (unsigned long) memaddr, len, ignore); */
p = buf;
*p++ = 'B';
if (type == 0)
*p++ = 'w';
else if (type == 1)
*p++ = 'r';
else if (type == 2)
*p++ = 'a';
else
error ("(_o_) sorry...watchpoint has wrong value for 'type' ");
p += hexnumstr (p, (ULONGEST) addr);
*p++ = ',';
p += hexnumstr (p, (ULONGEST) len);
*p++ = ',';
ignore_count = 0;
ALL_BREAKPOINTS_SAFE(b, tmp)
{
if (b->exp != NULL) {
v = evaluate_expression (b->exp);
watch_addr = VALUE_ADDRESS(v) + VALUE_OFFSET(v);
if ( watch_addr == addr) {
ignore_count = b->ignore_count;
b->ignore_count = 0;
break;
}
}
}
p += hexnumstr (p, (ULONGEST) ignore_count);
*p++ = ':';
*p = '\0';
putpkt (buf);
getpkt (buf, 0);
return 0; /* 0 when success, -1 when failure */
}
---------------------- cut cut cut ----------------------
Best regards,
Fukuda, M
From ac131313@cygnus.com Wed Sep 22 23:16:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Context attached to a command?
Date: Wed, 22 Sep 1999 23:16:00 -0000
Message-id: <37E9C499.19EF2B1E@cygnus.com>
X-SW-Source: 1999-q3/msg00374.html
Content-length: 458
Hello,
Do any of the existing command.h functions allow you to associate some
sort of context with the command?
For instance, add_cmd() takes a function
callback(char*arg, int from_tty);
the assumption being that the function can pick up any relevant data
from globals. Is there an equivalent:
calloback(void *context, char *arg, int from_tty);
where ``context'' was passed to the original add_command? If not, I'll
add it.
Andrew
From jtc@redback.com Thu Sep 23 13:53:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Masahiro Fukuda <masahiro@lsi.nec.co.jp>
Cc: gdb@sourceware.cygnus.com
Subject: Re: one proposal ... `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT ??
Date: Thu, 23 Sep 1999 13:53:00 -0000
Message-id: <5mg1051hdv.fsf@jtc.redbacknetworks.com>
References: <199909220933.SAA06550@mctcs13.ucom.lsi.nec.co.jp>
X-SW-Source: 1999-q3/msg00375.html
Content-length: 2635
>>>>> "Masahiro" == Masahiro Fukuda <masahiro@lsi.nec.co.jp> writes:
Masahiro> My name is Masahiro Fukuda. Independently, I added some
Masahiro> keyword (actually [B/b] just like J.T.C did) into gdb serial
Masahiro> protocol in order to transmit "breakpoint" to gdbserver
Masahiro> instead of writing TRAP instruction.
Masahiro> Some arguements including <addr>, <length>, <ignore_count>
Masahiro> follow breakpiont keyword in my code. Those command packets
Masahiro> are generated in v850_insert_hw_breakpint()/
Masahiro> v850_insert_watchpoint() in v850-tdep.c.
I didn't think about breakpoints with ignore counts when developing
the breakpoint extension proposal. I did want to allow the stub to
manage thread specific breakpoints, which are similar. I also spent
some time thinking about how to support conditional breakpoints. My
current thoughts are to use an easily parsed stack based expression
syntax, but I'm not actively pursuing this feature.
The problem with breakpoints with ignore counts is the synchronization
of the count between GDB and the stub. As I understand your proposal,
you address this by having the 'remove breakpoint' command return how
many counts are left for each breakpoint.
Unfortunately, I believe that this conflicts with another project that
I'm working on. I've been changing GDB so that breakpoints are not
inserted or removed from the target unless it is absolutely necessary
to do so.
At present, whenever you step through code, the active breakpoints are
inserted, the code is executed, then the breakpoints are removed. If
the user is using a lot of breakpoints, this greatly increases the
time it takes to step through code.
If GDB must sync ignore counts by removing breakpoints, that precludes
this optimization. Perhaps an additional command that lists managed
breakpoints and their ignore count (if any) is needed.
Another possible problem is that our current model is that duplicate
breakpoints are ignored when they are inserted. A breakpoint is
uniquely defined by <type>, <addr>, <len>, and possibly <thread-id> if
threads specific breakpoints are supported. But how can the stub tell
the differences between two breakpoints when the only difference is
the ignore count? This may require the stub to return a handle when a
breakpoint is inserted so that GDB can uniquely identify it.
I'm not saying this is a bad idea. Actually, this is the kind of
thing a stub can keep track of fairly trivally yet greatly reduce
the amount of debug protocol overhead. But I think it needs a bit
more refinement.
Thoughts?
--jtc
--
J.T. Conklin
RedBack Networks
From shenoy@wipinfo.soft.net Thu Sep 23 22:30:00 1999
From: "Narayan Shenoy R" <shenoy@wipinfo.soft.net>
To: <gdb@sourceware.cygnus.com>
Subject: Support for native Sun Workshop debugging format ...
Date: Thu, 23 Sep 1999 22:30:00 -0000
Message-id: <199909240530.LAA02001@gem.wipinfo.soft.net>
X-SW-Source: 1999-q3/msg00376.html
Content-length: 482
We are using native WorkShop debugging format (non -xs) for building our
parallel applications. gdb is known to have problems recognizing this
format. Reverting to -xs format is unacceptable since each of the libraries
build that way occupies close to 150 MB of space.
Are there any plans on supporting native WorkShop debugging format? If so,
any pointers to anyone who is working on that at present.
Please help.
Thanks,
Shenoy
Narayan Shenoy R
ph: 5530034/35/36 extn. 1055
^ permalink raw reply [flat|nested] 4+ messages in thread
* -Wmissing-prototypes ...
@ 1999-11-27 18:50 Andrew Cagney
1999-09-20 0:46 ` -Wmissing-prototypes Andrew Cagney
[not found] ` <37CB6DBE.2083662F@cygnus.com>
0 siblings, 2 replies; 4+ messages in thread
From: Andrew Cagney @ 1999-11-27 18:50 UTC (permalink / raw)
To: gdb
FYI,
There is now a reasonable chance that GDB can be compiled with the
-Wmissing-prototypes option. Thanks to JimI, JimB and Fernando and
Elena for various specific cleanups.
Andrew
My current list is:
--enable-build-warnings=-Werror\
,-Wimplicit\
,-Wreturn-type\
,-Wcomment\
,-Wtrigraphs\
,-Wformat\
,-Wparentheses\
,-Wpointer-arith\
,-Wmissing-prototypes\
,-Woverloaded-virtual\
From cgf@cygnus.com Sat Nov 27 18:50:00 1999
From: cgf@cygnus.com (Chris Faylor)
To: gdb@sourceware.cygnus.com
Subject: Re: Debugging Windows Namespace extension dll
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <7rpjdk$a2b$1@cronkite.cygnus.com>
References: <l03130300b404ff236a3b@[138.251.135.28]>
X-SW-Source: 1999-q4/msg00333.html
Content-length: 1219
In article <l03130300b404ff236a3b@[138.251.135.28]>,
Mark Hindley <mh15@st-andrews.ac.uk> wrote:
>I am in the middle of writing a windows namespace extension implemented as
>an in process server dll. I have got the basic structure complete and it
>builds fine with gcc, but I can not get it to debug with gdb.
>
>I am trying:
>
>exec-file /windows/explorer.exe
>
>source-file MyDll.dll
>
>set args /root, {My CLSID},
>
>
>There appears to be 2 problems. I get an access violation when the dll is
>read, eith as the initial symbol file, or when it is loaded by explorer
>when the programme is run. The other is that I am unable to set any
>breakpoints. If I type
>
>break DllMain
>
>the reply is
>
>Cannot access memory at 0x....
The way that I normally do something like this is:
gdb /windows/explorer.exe
symbol-file MyDll.dll
set args /root
l DllMain
bp <first line number in DllMain>
run
As you probably, know using 'symbol-file' wipes out any existing symbol file
so this may not be exactly what you want. You could use add-sym if you know
the load address of your DLL.
Hope this helps,
Chris Faylor
--
cgf@cygnus.com
http://www.cygnus.com/
From ac131313@cygnus.com Sat Nov 27 18:50:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: -Werror -Wformat -Wimplicit
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37CB6DBE.2083662F@cygnus.com>
X-SW-Source: 1999-q4/msg00334.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 msnyder@cygnus.com Sat Nov 27 18:50:00 1999
From: Michael Snyder <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Cc: ptr@paragraph.ru
Subject: Re: gdb 4.18 on Solaris 7 x86?
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37CC6A59.5106@cygnus.com>
References: <14273.5137.480144.257285@icecle>
X-SW-Source: 1999-q4/msg00339.html
Content-length: 1844
Petr Ovchenkov wrote:
>
> Is anybody made 4.18 working under Solaris 7 x86?
I don't have a Solaris 7 x86 system, but it works
fine for me on Solaris 6 x86. I'm not sure what
might have changed in Solaris 7.
> I made changes in gdb/procfs.c so no more
> "Inappropriate ioctl for device" happens, and correct permittions for
> /proc/XXXX/crt. But still can't set any breakpoint (indeed can,
> but gdb don't stop on it).
Can't comment without seeing your changes.
I've never seen that message, and breakpoints are
working fine for me on Solaris 6 x86.
> > more test.c
> #include <stdio.h>
>
> int main( int argc, char **argv )
> {
> printf( "%s", "Hello, GNU!\n" );
> return 0;
> }
> > gcc -ggdb test.c -lthread
Just curious -- why are you linking libthread to this program?
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-pc-solaris2.7"...
> (gdb) break main
> Breakpoint 1 at 0x80489b2: file test.c, line 5.
> (gdb) run
> Starting program: /export/home/ptr/tmp/Test/a.out
> Hello, GNU!
> /proc/11504/ctl: No such file or directory.
> procfs_write_pcwstop failed
> (gdb) quit
> The program is running. Exit anyway? (y or n) y
> >
>
> When gdb say "/proc/11504/ctl: No such file or directory.", process
> already exited. When I try "target solaris-thread", result the same.
>
> Can any help?
>
> If somebody interesting by /proc/... workaround for Solaris 7,
> patch for available.
I'd be willing to look at your patch.
Michael Snyder
From jingham@leda.cygnus.com Sat Nov 27 18:50:00 1999
From: James Ingham <jingham@leda.cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Next release of GDB
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <mf4sh6el89.fsf@leda.cygnus.com>
References: <199909051618.SAA01412@caracol.first.gmd.de>
X-SW-Source: 1999-q4/msg00341.html
Content-length: 1942
Clemens Klein-Robbenhaar <robbe@prosun.first.gmd.de> writes:
Presumably, the Objective C support would be in the MacOS X Support
bits. MacOS X being based on NextStep, which is in turn heavily
Objective C based...
Jim
> Stan Shebs wrote:
>
> [...]
> > Here are some additional things that I would like to see, but that
> > ought not to hold up the release if they can't be gotten in:
> >
> > * first version of libgdb, w/Guile scripting
> > * GNU/Linux thread_db library support
> > * asynchronous execution for GNU/Linux
> > * fork following for GNU/Linux
> > * HP WDB 1.1 bits
>>>>>>>>>>>> > * Apple MacOS X support bits
> > * Current VxWorks (Tornado) support bits
> > * Current LynxOS support bits
> > * m68k BDM patches
> > * Ada language support
> >
> > There are probably many other important things that I'm forgetting,
> > please speak up and remind me about them!
> [...]
>
> .. what about Objective C support? That should not be to hard.
> (For gdb-4.16 and gdb-4.17, there was a patch,
> afaik by Michael Snyder <msnyder@NeXT.com>;
> still present at ftp://alpha.gnu.org/gnu/gnustep/contrib
> This patch does not work for gdb-4.18, but only because the code
> changed too much for the "patch" program to apply, I think.)
>
> Have I missed some point here -- has the Objective C patch
> been rejected because of pricipal reasons not supporting Objective C
> in gdb? As I scanned the archives, I found only
> Christopher Seawood <cls@seawood.org>
> http://sourceware.cygnus.com/ml/gdb-patches/1998/msg00115.html
> raising the same issue, but without getting any feedback.
>
> Or has just nobody been around so far interested in doing the
> (little) work?
>
>
> regards,
> clemens
--
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham jingham@cygnus.com
Cygnus Solutions Inc.
From msnyder@cygnus.com Sat Nov 27 18:50:00 1999
From: Michael Snyder <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: overlays and hardware breakpoints
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37D5CAFE.7F3B@cygnus.com>
References: <5mwvu8ft9t.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00343.html
Content-length: 386
J.T. Conklin wrote:
> But while studying breakpoint.c, I noticed that there does not seem
> to be support for using hardware breakpoints and overlays. Although
> CPUs with hardware breakpoint registers typically have large address
> spaces, it is not inconceivable that overlays may be used.
Almost surely an oversight. If you care to add it,
I'll review it.
Michael
From ac131313@cygnus.com Sat Nov 27 18:50:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: ERF TARGET_WAITKIND_EOF
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <37F0529C.B0694A78@cygnus.com>
X-SW-Source: 1999-q4/msg00337.html
Content-length: 1119
Hello,
(I've also seen LOST, DEAD, DOA, KABOOM, KAPUT ..suggested :-).
At present when communication with a target is lost, the target
internally indicates the falure by directly killing the target
(mourn_inferior()) and longjmping out of there (error ()).
When it comes to async and providing clean library like behavour, having
things randomly call error() isn't nice (besides longjmp's are bad N'kay
;-).
I'd like to propose the new ``enum target_waitkind'' TARGET_WAITKIND_EOF
that target_wait() can return to indicate that the target just went
kaput. The semantics would require the target_*() vector to post the the
failure reason on gdb_stderr and then return TARGET_WAINTKIND_EOF.
Initially the remote async and remote extended-async targets would be
the only ones capable of returning this result. This would ensure that
other non-async targets would not be affected.
Clearly this is going to stur up WFI (or what ever it is today).
I'd like comments on this and (perhaphs) someone willing to handle the
WFI side. I'd be willing to take care of the remote.c side.
Andrew
From msnyder@cygnus.com Sat Nov 27 18:50:00 1999
From: "Michael Snyder" <msnyder@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Lets talk to each other...
Date: Sat, 27 Nov 1999 18:50:00 -0000
Message-id: <7svnb4$5cb$1@cronkite.cygnus.com>
References: <19990927151348.A22339@sco.com> <990928043014.ZM29997@ocotillo.lan> <199909280657.IAA00175@delius.kettenis.nl> <990929033103.ZM17365@ocotillo.lan> <199909291554.RAA18158@landau.wins.uva.nl>
X-SW-Source: 1999-q4/msg00345.html
Content-length: 307
Mark Kettenis wrote in message <199909291554.RAA18158@landau.wins.uva.nl>...
>HJ's patch has
>the drawback that it also tries to solve a totally unrelated problem
>(curses on Solaris 7), which needs some more investigation and
>probably should be
And is being.
>fixed in autoconf instead.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: -Wmissing-prototypes ...
[not found] ` <199912021414.JAA16068@mescaline.gnu.org>
@ 1999-12-02 7:42 ` Andreas Jaeger
0 siblings, 0 replies; 4+ messages in thread
From: Andreas Jaeger @ 1999-12-02 7:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb, Andrew Cagney, DJ Delorie
>>>>> Eli Zaretskii writes:
>> My current list is:
>>
>> --enable-build-warnings=-Werror\
>> ,-Wimplicit\
>> ,-Wreturn-type\
>> ,-Wcomment\
>> ,-Wtrigraphs\
>> ,-Wformat\
>> ,-Wparentheses\
>> ,-Wpointer-arith\
>> ,-Wmissing-prototypes\
>> ,-Woverloaded-virtual\
[...]
Eli> Here are the patches for go32-nat.c to allow it to compile with all
Eli> kinds of -Wfoo switches (I added switches beyond those mentioned above).
Eli> +static void print_387_status (unsigned, struct env387 *);
Shouldn't this be unsigned int? AFAIK the new ISO C99 standard
mandates it - and it doesn't harm here.
Eli> static void
Eli> -print_387_status (unsigned short status, struct env387 *ep)
Eli> +print_387_status (unsigned status, struct env387 *ep)
Again: unsigned int
Eli> + print_387_control_word ((unsigned)ep->control & 0xffff);
unsigned int
I didn't look at the rest,
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de
From grante@visi.com Thu Dec 02 07:49:00 1999
From: Grant Edwards <grante@visi.com>
To: William Gatliff <gatliff@haulpak.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Thu, 02 Dec 1999 07:49:00 -0000
Message-id: <19991202094847.A1826@visi.com>
References: <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com>
X-SW-Source: 1999-q4/msg00418.html
Content-length: 1858
On Thu, Dec 02, 1999 at 08:43:51AM -0600, William Gatliff wrote:
> > Packet Structure:
> >
> > Simple structure, obviously originally designed to be able to be driven
> > manually from a TTY. (Hence it's ASCII nature.) However, the protocol has
> > evolved quite significantly and I doubt it could still be used very
> > efficiently from a TTY.
>
> True, but it can still be *monitored* quite effectively with a TTY,
And this is a Very Good Thing. Debugging the RDI target stuff was a
pain because of the binary packet format. Even after adding of
packet-logging routines, it still wasn't obvious what was wrong.
Fortunately, I do that sort of stuff for a living and have an HP
protocol analyzer sitting handy. :)
Most of the features in the RDI packet protocol either don't work or
aren't used, so a simpler ASCII protocol would have served just as
well.
An ASCII protocol also allows you to whip together a quick simulator
for either end using something like expect (and netcat if you want to
do TCP/IP). This can save your ass big time when trying to isolate
problems.
> and simple things like a ? query are still possible. If I'm using a
> TTY then I'm desperate anyway, so I'm willing to put up with a
> little pain. Go to a non-ASCII protocol, however, and the TTY
> option is right out altogether, no matter how desperate I am!
>
> If efficiency/throughput is a problem, then go to ethernet. At
> 10/100Mbps, even the overhead of ASCII isn't a problem for most
> targets I can think of.
Definitely. The RDI packet stuff is binary, but it's still only
pleasant to use via Ethernet. For example, a "next" involves
exchanging about a half-dozen packets, and even when they're in
binary, doing it via RS-232 involves an annoyinge delay when you're
used to seeing the green arrow in DDD move instantly..
--
Grant Edwards
grante@visi.com
From ezannoni@cygnus.com Thu Dec 02 08:31:00 1999
From: Elena Zannoni <ezannoni@cygnus.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: using '-x -' to read gdb script from stdin
Date: Thu, 02 Dec 1999 08:31:00 -0000
Message-id: <14406.40674.819682.91859@kwikemart.cygnus.com>
References: <5miu2hhgkx.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00419.html
Content-length: 2091
J.T. Conklin writes:
> I updated one of our year old GDB executables a week or so ago, and
> was notified that one of the scripts used by SQA failed to work. I
> tracked it down to the following bit of code that was ifdef'd out
> earlier this year.
>
> >From main.c:
> /* NOTE: I am commenting this out, because it is not clear
> where this feature is used. It is very old and
> undocumented. ezannoni: 1999-05-04 */
> #if 0
> if (cmdarg[i][0] == '-' && cmdarg[i][1] == '\0')
> read_command_file (stdin);
> else
> #endif
>
>
> The script invoked gdb like this:
> echo list "*$addr" | $gdb -batch -x - $file | head -1
>
> [ I know, I should be using addr2line. But this script was written
> before addr2line existed. ]
>
> Since all of our systems support /dev/stdin, I patched up our script
> accordingly. But I wonder whether support for - should be reenabled.
> Is there any reason why not?
>
> --jtc
>
JT,
If I remember correctly, invoking gdb with '-x -'
would start the command_loop() via read_command_file(), instead of
via captured_command_loop(). In case of async (which is now the default),
the traditional command_loop() is not called, because gdb_init() sets
command_loop_hook to cli_command_loop().
So we would have started the regular command loop, even though all the
necessary stuff for async was set up. Bad interactions would follow.
Since that option was not documented, it was decided to get rid of it
if nobody was going to be penalized. It may be still possible to
clean things up but I just noticed that it is not just a matter of
eliminating the #if 0, unfortunatley, because more surrounding code
has also been deactivated.
Using the source command works because that is invoked after the main
command loop has already started.
I can put this on my to do list, but it will be a while before I can
get to it. Feel free to give it a try if you want.
Elena
> --
> J.T. Conklin
> RedBack Networks
From sasumner@juno.com Thu Dec 02 09:51:00 1999
From: Scott A Sumner <sasumner@juno.com>
To: gdb@sourceware.cygnus.com
Subject: gdb build troubles
Date: Thu, 02 Dec 1999 09:51:00 -0000
Message-id: <19991201.205719.-370075.0.sasumner@juno.com>
X-SW-Source: 1999-q4/msg00420.html
Content-length: 1748
Hi,
I'm trying to build gdb with the Cygwin 1.0 CD toolset for an m68k
target.
Here's what I do:
bash-2.03$ ../gdb-4.18/configure --target=m68k-coff
And here's what happens:
Configuring for a i586-pc-cygwin32 host.
# post-target:
intl mmalloc libiberty opcodes bfd readline gash db tcl tk tcl8.1 tk8.1
tclX it
cl tix libgui byacc flex bison binutils ld gas gcc sim gdb make patch
prms send-
pr gprof gdbtest tgas etc expect dejagnu ash bash bzip2 m4 autoconf
automake lib
tool ispell grep diff rcs cvssrc fileutils shellutils time textutils
wdiff find
emacs emacs19 uudecode hello tar gzip indent recode release sed utils
guile perl
apache inet gawk findutils snavigator libtool gettext zip libtermcap
dosrel
grep: (standard input): Permission denied (EACCES)
grep: (standard input): Permission denied (EACCES)
intl mmalloc libiberty opcodes bfd readline gash db tcl tk tcl8.1 tk8.1
tclX it
cl tix libgui byacc flex bison binutils ld gas gcc sim gdb make patch
prms send-
pr gprof gdbtest tgas etc expect dejagnu ash bash bzip2 m4 autoconf
automake lib
tool ispell grep diff rcs cvssrc fileutils shellutils time textutils
wdiff find
emacs emacs19 uudecode hello tar gzip indent recode release sed utils
guile perl
apache inet gawk findutils snavigator libtool gettext zip libtermcap
dosrel
grep: (standard input): Permission denied (EACCES)
grep: (standard input): Permission denied (EACCES)
<REPEATS FOREVER ANNOYINGLY SPINNING THE FLOPPY DRIVE>
Can anyone give me a hint as to my problem?
Scott A. Sumner
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj .
From jtc@redback.com Thu Dec 02 10:36:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: using '-x -' to read gdb script from stdin
Date: Thu, 02 Dec 1999 10:36:00 -0000
Message-id: <5m4se1mbq3.fsf@jtc.redbacknetworks.com>
References: <5miu2hhgkx.fsf@jtc.redbacknetworks.com> <14406.40674.819682.91859@kwikemart.cygnus.com>
X-SW-Source: 1999-q4/msg00421.html
Content-length: 1367
>>>>> "Elena" == Elena Zannoni <ezannoni@cygnus.com> writes:
Elena> Since that option was not documented, it was decided to get rid
Elena> of it if nobody was going to be penalized. It may be still
Elena> possible to clean things up but I just noticed that it is not
Elena> just a matter of eliminating the #if 0, unfortunatley, because
Elena> more surrounding code has also been deactivated.
Elena> I can put this on my to do list, but it will be a while before
Elena> I can get to it. Feel free to give it a try if you want.
There's no rush. Using /dev/stdin works for now, and I hope to adapt
the script to use binutils' addr2line utility in the near future.
After thinking this over a bit, reading commands from stdin may not be
the best way to support 'command line' batch scripting. Perhaps it
should be done with a command line option instead. Maybe something
like this:
gdb -batch --eval "list *$addr"
The current command interpreter doesn't have a statement separator so
that multiple commands can be put on one line, but it may be possible
to add one. I tried appending a semicolon to a handful of commands
and they all bailed out with syntax errors of one sort or another.
Something to think about. Since my immediate problem has been solved,
I'm going to put this on the back burner.
--jtc
--
J.T. Conklin
RedBack Networks
From davidwilliams@ozemail.com.au Thu Dec 02 10:49:00 1999
From: David Williams <davidwilliams@ozemail.com.au>
To: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: exceptionHandler for 68K
Date: Thu, 02 Dec 1999 10:49:00 -0000
Message-id: <01BF3D51.ED385300.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00422.html
Content-length: 418
Hi all,
Has anyone got an example of the exceptionHandler() function for the 68K
(plain old 68000 core). The m68k-stub.c module requires one (as explained
in GDB manual). However it appears that this function must use its own
special vector table to help identify the vector number (using return
address magic!). It would just be nice to see some source code to clarify
some issues for me.
TIA
David Williams.
From davidwilliams@ozemail.com.au Thu Dec 02 10:55:00 1999
From: David Williams <davidwilliams@ozemail.com.au>
To: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: gdb stack in stub
Date: Thu, 02 Dec 1999 10:55:00 -0000
Message-id: <01BF3D52.CD93EEA0.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00423.html
Content-length: 596
Hi all,
I noticed that a 10K local stack is allocated in the m68k-stub.c for it own
use when communcating with gdb. This seems excessive. I would like to leave
the stub code in my final application so that I can debug in the field (via
a special option). However it would be better if the stub consumed the
least amount of system resources as possible.
Is there any problem with using my applications stack (if enough room is
allocated for GDB usage in addition to normal usage)? My application always
runs in supervisor mode.
What is likely max stack usage of GDB?
TIA
David Williams.
From jtc@redback.com Thu Dec 02 11:12:00 1999
From: jtc@redback.com (J.T. Conklin)
To: "davidwilliams@ozemail.com.au" <davidwilliams@ozemail.com.au>
Cc: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: Re: gdb stack in stub
Date: Thu, 02 Dec 1999 11:12:00 -0000
Message-id: <5mvh6hkvi6.fsf@jtc.redbacknetworks.com>
References: <01BF3D52.CD93EEA0.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00424.html
Content-length: 1636
>>>>> "David" == David Williams <davidwilliams@ozemail.com.au> writes:
David> Hi all, I noticed that a 10K local stack is allocated in the
David> m68k-stub.c for it own use when communcating with gdb. This
David> seems excessive. I would like to leave the stub code in my
David> final application so that I can debug in the field (via a
David> special option). However it would be better if the stub
David> consumed the least amount of system resources as possible.
David>
David> Is there any problem with using my applications stack (if
David> enough room is allocated for GDB usage in addition to normal
David> usage)? My application always runs in supervisor mode.
Yes. The problem occurs when you attempt an inferior function call.
GDB starts constructing a dummy stack frame at the saved stack ptr,
which overwrites the stack memory being used by the stub itself.
David> What is likely max stack usage of GDB?
The stub code itself doesn't use much stack, but the user-supplied
putDebugChar() and getDebugChar() functions might. I typically do
i/o with loops polling UART registers, which isn't stack intensive.
I've measured stack use of our PowerPC based stub at less than 100
bytes. A CPU like the m68k where function arguments and return
addresses are passed on the stack may take a bit more.
You might want to allocate a stack you know will be big enough,
initialize it with a given pattern, use the stub for a while and then,
examine the stack to determine where the pattern has been overwritten.
That should give you a good idea how to size the stack in your system.
--jtc
--
J.T. Conklin
RedBack Networks
From jtc@redback.com Thu Dec 02 15:04:00 1999
From: jtc@redback.com (J.T. Conklin)
To: "davidwilliams@ozemail.com.au" <davidwilliams@ozemail.com.au>
Cc: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: Re: exceptionHandler for 68K
Date: Thu, 02 Dec 1999 15:04:00 -0000
Message-id: <5mr9h5kkt7.fsf@jtc.redbacknetworks.com>
References: <01BF3D51.ED385300.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00425.html
Content-length: 1692
>>>>> "David" == David Williams <davidwilliams@ozemail.com.au> writes:
David> Has anyone got an example of the exceptionHandler() function
David> for the 68K (plain old 68000 core). The m68k-stub.c module
David> requires one (as explained in GDB manual). However it appears
David> that this function must use its own special vector table to
David> help identify the vector number (using return address
David> magic!). It would just be nice to see some source code to
David> clarify some issues for me.
Although the debug stubs distributed with GDB can be used without
modification, there is no reason why you must do so.
Exception handling mechanisms are target dependent. If you're happy
with the exception mechanism you are currently using (or the one you
have designed, if you're not that far), In my opinion it is better to
adapt the debug stubs exception handler installation code rather than
to force your system to match.
All that being said...
It's been a long time since I've used the m68k, but if I remember
correctly the addresses of exception handlers are stored in a 256
entry table, the address of which is stored in a exception vector
table base register.
In C, you might do something like this to install an address:
void *exc_tbl[256];
void
exceptionHandler(int vec, void *addr)
{
exc_tbl[vec] = addr;
}
In assembly, the code might be something like this:
#
# Inputs:
# d0 - vector
# d1 - address of exception handler
# a0 - address of exc_tbl
#
move.l %d1,(%a0,%d0.l*4)
Hope this helps,
--jtc
--
J.T. Conklin
RedBack Networks
From davidwilliams@ozemail.com.au Thu Dec 02 15:15:00 1999
From: David Williams <davidwilliams@ozemail.com.au>
To: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: RE: exceptionHandler for 68K
Date: Thu, 02 Dec 1999 15:15:00 -0000
Message-id: <01BF3D76.F8F982C0.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00426.html
Content-length: 3671
Hi,
Although the debug stubs distributed with GDB can be used without
modification, there is no reason why you must do so.
Exception handling mechanisms are target dependent. If you're happy
with the exception mechanism you are currently using (or the one you
have designed, if you're not that far), In my opinion it is better to
adapt the debug stubs exception handler installation code rather than
to force your system to match.
Good Advice, and in fact what I was already considering. However I wish to
understand the exisiting m68k-stub.c better to decide if what is being done
is useful and worth adapting. Please note my target (68EZ328) has a 68000
core, not CPU32, so when exceptions occur there is no vector number stored
on the stack.
I get the idea of what the m68k-stub.c (supplied with gdb4.18) is trying to
do without understanding the full detail. The 68000 does not provide the
vector number when an exception occurs. To get arround this the stub
assumes that you orgainise the real 68K vectors to point to a table of 'jsr
handler' op-codes. Then when the exception occurs the CPU stacks the
current PC(program counter) and SR(status register) looks up the vector and
loads the PC with the value in the vector. The new PC will be somewhere in
the jsr table. The CPU then executes the jsr in the table which causes the
CPU to stack the return address (location in the jsr table) and then jump
to the exception handler. My problem is that I dont understand where this
table of jsr's is located...
The m68k-stub has code to determine the exception number by taking the
return address on the stack (the return address is the location in the jsr
table) and adding 1530 and then dividing by 6.
The relevent comments in the source are
"Some explanation is probably necessary to explain how exceptions are
handled. When an exception is encountered the 68000 pushes the current
program counter and status register onto the supervisor stack and then
transfers execution to a location specified in it's vector table. The
handlers for the exception vectors are hardwired to jmp to an address given
by the relation: (exception - 256) * 6. These are decending addresses
starting from -6, -12, -18, ... By allowing 6 bytes for
each entry, a jsr, jmp, bsr, ... can be used to enter the exception
handler. Using a jsr to handle an exception has an added benefit of
allowing a single handler to service several exceptions and use the return
address as the key differentiation. The vector number can be computed from
the return address by [ exception = (addr + 1530) / 6 ].
The sole purpose of the routine _catchException is to compute the exception
number and push it on the stack in place of the return address. The
external function exceptionHandler() is used to attach a specific handler
to a specific m68k exception."
Any help would be appreciated.
All that being said...
It's been a long time since I've used the m68k, but if I remember
correctly the addresses of exception handlers are stored in a 256
entry table, the address of which is stored in a exception vector
table base register.
In C, you might do something like this to install an address:
void *exc_tbl[256];
void
exceptionHandler(int vec, void *addr)
{
exc_tbl[vec] = addr;
}
In assembly, the code might be something like this:
#
# Inputs:
# d0 - vector
# d1 - address of exception handler
# a0 - address of exc_tbl
#
move.l %d1,(%a0,%d0.l*4)
Thanks for the code, unfortunately this does not address my problem - see
notes above.
From sbjohnson@ozemail.com.au Thu Dec 02 16:19:00 1999
From: Steven Johnson <sbjohnson@ozemail.com.au>
To: gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Thu, 02 Dec 1999 16:19:00 -0000
Message-id: <38470CC1.1B0E5C27@ozemail.com.au>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com> <3845AB0E.3795D99E@ozemail.com.au> <5md7sql00o.fsf@jtc.redbacknetworks.com> <3845F45A.38EA29CF@ozemail.com.au> <384685A7.15184EB1@haulpak.com>
X-SW-Source: 1999-q4/msg00427.html
Content-length: 5990
William Gatliff wrote:
>
> Steven Johnson wrote:
>
> > Packet Structure:
> >
> > Simple structure, obviously originally designed to be able to be driven
> > manually from a TTY.
>
> True, but it can still be *monitored* quite effectively with a TTY, and
> simple things like a ? query are still possible.
Im not criticizing or suggesting a change, im making an observation.
Whether $ or STX or some other packet structure is used is of little
import. Advantageously, the GDB packet structure is complete and
independent from the message it contains. Which is a good thing. This is
very different from many "proprietary" binary protocols i've used where
the packet and message are confused and mingled, so that there is no
good separation of packet handling and messaging. I actually found this
a nice surprise, from all of the protocols i've dealt with few people
seem to realize the importance of this in good comms design.
>
> If efficiency/throughput is a problem, then go to ethernet.
>
I wasn't suggesting it was in-efficient to use from a program. I was
making the general statement that it would be difficult to debug a
target just using a TTY and a target with the stub. Efficiency meant,
time in working out the message to key in and deciphering the response.
You have no arguments from me that being able to easily observe the
message stream for the purposes of debugging an implementation is a good
thing.
>
> Good suggestions, but I would prefer that these be general stub design
> guidelines that aren't enforced by gdb. Let gdb be as flexible as
> possible, so that it will work with super-smart stubs that do all the
> timing stuff properly, as well as stubs that are minimally written.
>
Yes, here's the issue. The document is completely lacking in stub
implementation guidelines. IMHO, there needs to be a section of the
protocol (or comments throughout it) that give this sort of information
and advice to implementers of stubs. An implementer can then take it or
leave it, but at least the document needs to advise how a well behaved
stub could/should operate. There needs to be more than just "Here is a
Packet", there also needs to be documentation along the lines of "Here
is a Packet, a receiver should do this when it gets it. Possible
problems in reception are, some solutions to these problems are." It
would add meat to the bones that are currently described and aid in the
implementation/debugging of a stub.
>
> Gdb is supposed to be a debugging aid; I would prefer that all the protocol
> stuff not get in the way of its fundamental mission.
>
I'm not suggesting it does.
> Also, how do you measure byte times on most debugging hosts, particularly
> at 115K (my bit rate of choice) and higher?
>....<snip>
>
No arguments here either, I was speculating about possible solutions. I
wasn't saying this must be done. I would agree there are many ways to
skin that cat, and some are easier than others, depending on your host.
I also recognize that stubs probably don't do this now and the world
hasn't come to an end.
> > There is no documentation of the recovery procedure, Does GDB retransmit
> > if its message is responded to with a NAK? If not, what does it do? How
> > is the target supposed to identify and handle retransmits from GDB.
>
> > What happens if something other than + or - is received when ACK/NAK is
> > expected. (For example $).
>
> >From my own experience, remote.c is kinda fragile where stuff like this is
> concerned. I had been intending to look into this myself next year, but by
> then someone else will have certainly beaten me to it. I think some
> improvements have already been made.
>
I see this as a far more important issue than the timeout stuff,
although they are related. Remote.c is probably fragile, because there
is no documentation on how it should work. It wouldn't surprise me if
there was inconsistency of the implementation in GDB because of this.
> > Character Escaping: The mechanism of Escaping the characters is not
> > defined. Further it is only defined as used by write mem binary.
>
> That's because this is the only place where it is needed, AFAIK. And,
> since X is optional (and support for it is detected automatically by gdb),
> that means that I don't have to implement it if I don't want to. Bonus for
> super-minimal stubs.
>
Again I agree with this. I was making the observation that Character
Escaping is likely to become more prevalent as the protocol evolves. To
define character escaping around one message could create a situation
where different messages that require it implement different mechanisms.
There is evidence of that occurring in other messages, like the ':'
shouldn't be used, but some messages do statement.
What would probably be more appropriate is to state how escaping is
performed where required as part of the base level protocol. Then in the
message put a statement like, "This message contains binary data and
must be Escaped using the standard escaping mechanism defined above".
This way if you don't implement any of those messages, you don't need to
implement Escaping. But it advantageous in that it defines how escaping
will be used in any/all messages that require it. I think the same
should be said for RLE. Maybe each message needs a check list that
states what features it may use like this:
My new Message U My comments on this message
Uses RLE: NO
Uses ESC: YES
At least this would clearly state where both of these mechanisms can be
used, and where they can't.
Further, Im not stating any implementation should change. What Im trying
to do is come to terms with the documented protocol. Identify weaknesses
in that documentation and propose ways the document can be strengthened
to more accurately reflect what is desired of an implementation.
Steven Johnson
Managing Director
Neurizon Pty Ltd
From shebs@cygnus.com Thu Dec 02 19:05:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: alexs@cygnus.co.uk
Cc: gdb@sourceware.cygnus.com
Subject: Re: Multi-threaded debugging within GDB & eCOS
Date: Thu, 02 Dec 1999 19:05:00 -0000
Message-id: <199912030305.TAA24626@andros.cygnus.com>
References: <77kid9$pqp$1@korai.cygnus.co.uk>
X-SW-Source: 1999-q4/msg00428.html
Content-length: 1641
From: "Alex Schuilenburg" <alexs@cygnus.co.uk>
Date: Thu, 14 Jan 1999 11:04:23 -0000
Could someone describe how gdb would handle the following situation in
debugging multiple threads using gdb (particularly on eCOS)? Has anyone
thought of this scenario before?
1) gdb is tracking thread A, which claims a system mutex.
2) Either a context switch occurs or the user suspends thread A and
switches to debugging thread B (which itself is suspended).
3) While stepping over fn calls within B, the code attempts to claim
the mutex already owned by A. Hence B will never return from the call
to the next temporary breakpoint until A is resumed and releases the
mutex.
Will gdb lock up? Is there any mechanisim to allow gdb to detect/catch this
scenario and report back to the user what has happened?
GDB will "lock up". More precisely, GDB will sit quietly waiting for
the target to do something, not realizing that the user has caused a
deadlock by manually suspending thread A. This is as expected, since
GDB has no way to know that the program is in this state. In
practice, the user gets impatient, hits ^C, sees the current state,
and goes "oh yeah, my fault" and fixes.
GDB's default behavior is to give all threads a chance to run when
resuming, which generally prevents this kind of situation. We
introduced the scheduler-locking flag for those cases where the user
really really needs to lock out other threads, even if it might mean
the thread being stepped will block.
(I'd be interested to know if you have workarounds for this
fundamental problem though.)
Stan
From qqi@world.std.com Thu Dec 02 19:14:00 1999
From: Quality Quorum <qqi@world.std.com>
To: gdb@sourceware.cygnus.com
Subject: gdb & wiggler
Date: Thu, 02 Dec 1999 19:14:00 -0000
Message-id: <Pine.SGI.3.95.991202221018.1589A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00429.html
Content-length: 383
Hi,
I am working on the piece of code which will proived gdb-server like
servies for embedded systems. I would like to allow people
to use for interfacing with proprietary software (similar to
gdb <->wiggler.dll interface). I would prefer to publish it under
GPL, however, I have doubts whether or not interface like
gdb <-> wiggler is compliant with GPL ?
Thanks,
Aleksey
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: -Wmissing-prototypes ...
[not found] <Pine.SUN.3.91.991202192443.17848B-100000@is>
@ 1999-12-02 22:19 ` Andreas Jaeger
0 siblings, 0 replies; 4+ messages in thread
From: Andreas Jaeger @ 1999-12-02 22:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gdb, Andrew Cagney, DJ Delorie
>>>>> Eli Zaretskii writes:
Eli> On 2 Dec 1999, Andreas Jaeger wrote:
Eli> +static void print_387_status (unsigned, struct env387 *);
>> Shouldn't this be unsigned int? AFAIK the new ISO C99 standard
>> mandates it - and it doesn't harm here.
Eli> I didn't know we are supposed to be compatible with C9x. It's probably a
Eli> good idea to tell this explicitly, so all platform maintainers know.
That was a personal comment - I'm not a gdb maintainer.
Eli> Yes, you can change all places with "unsigned" into "unsigned int".
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.rhein-neckar.de
From toddpw@windriver.com Thu Dec 02 23:19:00 1999
From: Todd Whitesel <toddpw@windriver.com>
To: davidwilliams@ozemail.com.au
Cc: gdb@sourceware.cygnus.com (GDB Developers)
Subject: Re: exceptionHandler for 68K
Date: Thu, 02 Dec 1999 23:19:00 -0000
Message-id: <199912030719.XAA19824@alabama.wrs.com>
References: <01BF3D76.F8F982C0.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00431.html
Content-length: 997
> to the exception handler. My problem is that I dont understand where this
> table of jsr's is located...
Admittedly I have not looked at the code, but it may be generated by a macro,
so it might be easy to miss. You could try building a debug stub and objdump
it to see where all the vector table entries point to.
According to the discussion you posted, it sounds like there's a label called
'exception' and the 256 JSR's are stored underneath that. So maybe you should
search the source for references to that label?
> The m68k-stub has code to determine the exception number by taking the
> return address on the stack (the return address is the location in the jsr
> table) and adding 1530 and then dividing by 6.
Feh. Use BSR.W and divide by 4. Or chop up the table into four pieces, each
a row of BSR.S instructions jumping to slightly different computation code
at the bottom -- that lets you divide by 2 and save another 500 bytes or so.
--
Todd Whitesel
toddpw @ windriver.com
From ac131313@cygnus.com Thu Dec 02 23:22:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: "davidwilliams@ozemail.com.au" <davidwilliams@ozemail.com.au>
Cc: "'gdb mail list'" <gdb@sourceware.cygnus.com>
Subject: Re: gdb stack in stub
Date: Thu, 02 Dec 1999 23:22:00 -0000
Message-id: <38476F7E.B6A46989@cygnus.com>
References: <01BF3D52.CD93EEA0.davidwilliams@ozemail.com.au>
X-SW-Source: 1999-q4/msg00432.html
Content-length: 881
David Williams wrote:
>
> Hi all,
>
> I noticed that a 10K local stack is allocated in the m68k-stub.c for it own
> use when communcating with gdb. This seems excessive. I would like to leave
> the stub code in my final application so that I can debug in the field (via
> a special option). However it would be better if the stub consumed the
> least amount of system resources as possible.
>
> Is there any problem with using my applications stack (if enough room is
> allocated for GDB usage in addition to normal usage)? My application always
> runs in supervisor mode.
FYI,
GDB likes to perform inferior function calls on the target stack. Watch
the effect of:
(gdb) print printf ("Hello world\n")
If you try to use the target program's stack, GDB is very likely to
trash it :-(
enjoy,
Andrew
> What is likely max stack usage of GDB?
>
> TIA
> David Williams.
From ac131313@cygnus.com Fri Dec 03 00:52:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Steven Johnson <sbjohnson@ozemail.com.au>
Cc: jtc@redback.com, gdb@sourceware.cygnus.com
Subject: Re: Standard GDB Remote Protocol
Date: Fri, 03 Dec 1999 00:52:00 -0000
Message-id: <38478423.6ACE7BF8@cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org>
X-SW-Source: 1999-q4/msg00433.html
Content-length: 9163
Steven Johnson wrote:
> It is based on my First Read of the current online version of protocol
> specification at:
> http://sourceware.cygnus.com/gdb/onlinedocs/gdb_14.html
> Packet Structure:
>
> Simple structure, obviously originally designed to be able to be driven
> manually from a TTY. (Hence it's ASCII nature.) However, the protocol
> has evolved quite significantly and I doubt it could still be used very
> efficiently from a TTY. That said, it still demarks frames effectively.
One really useful thing to know is the command:
(gdb) set remotedebug 1
(If there isn't already) there should be a reference to that command (or
is successor).
> Sequence Numbers:
>
> Definition of Sequence ID's needs work. Are they necessary? Are they
> deprecated? What purpose do they currently serve within GDB? One would
> imagine that they are used to allow GDB to handle retransmits from a
> remote system. Reading between the lines, this is done to allow error
> recovery when a transmission from target to host fails. Possible
> sequence being:
I guess the best description is ``in limbo''. Sequence ID's have been in
the protocl for as long as anyone can remember but, at the same time no
one can actually remeber them being used. True?
I didn't deprecate it as there does need to be something for handling
things like duplicate packets (so that finally the protocol can be used
reliably across UDP and the like). Someone needs to sit down and fully
specify this (or better) identify an existing protocol that can be used
to specify the sequence-id's behavour.
There should at least be a note pointing out the current status of
sequence-ID's.
> The 2 primary timing constraints I see that are missing are:
>
> Inter character times during a message transmission, and Ack/Nak
> response times.
>
> If a message is only half received, the receiver has no ability without
> a timeout mechanism of generating a NAK signalling failed receipt. If
> this occurs, and there is no timeout on ACK/NAK reception, the entire
> comms stream could Hang. Transmitter is Hung waiting for an ACK/NAK and
> the Receiver is Hung waiting for the rest of the message.
>
> I would propose that something needs to be defined along the lines of:
>
> Once the $ character for the start of a packet is transmitted, each
> subsequent byte must be received within "n" byte transmission times.
> (This would allow for varying comms line speeds). Or alternately a
> global timeout on the whole message could be define one "$" (start
> sentinel) is sent, the complete message must be received within "X"
> time. I personally favour the inter character time as opposed to
> complete message time as it will work with any size message, however the
> complete message time restrict the maximum size of any one message (to
> how many bytes can be sent at the maximum rate for the period). These
> tiemouts do not need to be very tight, as they are merely for complete
> failure recovery and a little delay there does not hurt much.
How GDB behaves should be clarified. However, any definition should
avoid refering to absolute times and instead refer the user back to a
number of knobs that can be tweeked from the GDB command line.
This in turn suggests that there should be a section describing the
protocol's behavour with direct references to things like the
configurable timers.
I've sometimes wondered about doing a proper SDL spec.... :-)
> Identified Protocol Hole:
>
> Lets look at the following abstract scenario (Text in brackets are
> supporting comments):
>
> <- $packet-data#checksum (Run Target Command)
> -> + (Response is lost due to a line
> error)
> (Target runs for a very short period of time and then breaks).
> -> $sequence-id:packet-data#checksum (Break Response - GDB takes as a
> NAK, expecting a +, got a $).
> <- $packet-data#checksum (GDB retransmits it's Run Target Command,
> target restarts)
> -> + (Response received OK by GDB).
> (Target again starts running.)
That is correct.
The protocol, as it currently stands, is only robust against overrun
errors (detected by a checksum failure).
In pratice this has proven to be sufficient for almost all situtations.
Because of the request/response nature of the protocol the probably of a
dropped/corrupt ACK packet is very low. (I'm not saying this a good
thing, just a lucky thing :-)
This would suggest that at least the spec should make the known
limitations clear.
This is another reason why I've not simply abandoned the sequence-ID -
I'm hopeing someone will do something about this :-)
> Run Length Encoding:
>
> Is run length encoding supported in all packets, or just some packets?
> (For example, not binary packets)
> Why not allow lengths greater than 126? Or does this mean lengths
> greater than 97 (as in 126-29)
> If binary packets with 8 bit data can be sent, why not allow RLE to use
> length also greater than 97. If the length maximum is really 126, then
> this yields the character 0x9B which is 8 bits, wouldn't the maximum
> length in this case be 226. Or is this a misprint?
FYI, Any packet can be RLE. RLE handling is done as part of unpacking a
packet. The code doesn't know if it is binary/ascii at that point.
The old RLE size reflects the fact that a 7 bit printable character was
used (the actual equation is RLE - ' ' +3). While binary packets could
extend this, I don't think that there is any benefit.
I've rarely seen an RLE stub in pratice. The benefits would be
significant.
GDB doesn't send RLE packets and, I think, it should.
> Why are there 2 methods of RLE? Is it important for a Remote Target to
> understand and process both, or is the "cisco encoding" a proprietary
> extension of the GDB Remote protocol, and not part of the standard
> implementation. The documentation of "cisco encoding" is confusing and
> seems to conflict with standard RLE encoding. They appear to be mutually
> exclusive. If they are both part of the protocol, how are they
> distinguished when used?
It's an unsupported extension. Idea's from CISCO are slowly being
rolled back into the normal protocol.
> Deprecated Messages:
>
> Should an implementation of the protocol implement the deprecated
> messages or not? What is the significance of the deprecated messages to
> the current implementation?
(Your not the first one to ask that one :-)
They are there as a very strong deterant for people thinking of re-using
the relevant letters. This should probably be clarified.
> Character Escaping:
>
> The mechanism of Escaping the characters is not defined. Further it is
> only defined as used by write mem binary. Wouldn't it be useful for
> future expansion of the protocol to define Character Escaping as a
> global feature of the protocol, so that if any control characters were
> required to be sent, they could be escaped in a consistent manner across
> all messages. Also, wouldn't the full list of escape characters be
> $,#,+,-,*,0x7d. Otherwise, + & - might be processed inadvertently as ACK
> or NAK. If this can't happen, then why must they be avoided in RLE? If
> they are escaped across all messages, then that means they could be used
> in RLE and not treated specially.
Beyond the X packet there is no escape mechanism. GDB assumes the
connection is capable of transfering printable ascii. Escaping
characters should probably be left to a lower layer.
(A side note: The existing protocol spec mixes the packet specification
and transfer in with the specification of the actual packet body - not a
good way of defining a spec.)
> 8/7 Bit protocol.
>
> With the documentation of RAW Binary transfers, the protocol moves from
> being a strictly 7 bit affair into being a 8 bit capable protocol. If
> this is so, then shouldn't all the restrictions that are placed from the
> 7 bit protocol days be lifted to take advantage of the capabilities of
> an 8 bit message stream. (RLE limitations, for example). Would anyone
> seriously be using a computer that had a 7 bit limitation anymore
> anyway? (At least a computer that would run GDB with remote debugging).
I suspect that it will still be there for a while longer. Even if there
were no broken serial controllers there will still be broken stubs :-(
> Thoughts on consistency and future growth:
>
> Apply RLE as a feature of All messages. (Including binary messages, as
> these can probably benefit significantly from it).
>
> Apply the Binary Escaping mechanism as a feature of the packet that is
> performed on all messages prior to transmission and immediately after
> reception. Define an exhaustive set of "Characters to be escaped".
>
> Introduce message timing constraints.
>
> Properly define sequence-id and allow it to be used from GDB to make
> communications secure and reliable.
FYI, the one I really wish someone would persue is a mechanism that
allowed GDB to send console input down to the target. Cisco added code
that does something however it isn't robust.
To do this, I suspect that some of the other issues you've raised would
also need to be addressed.
thanks,
Andrew
From ac131313@cygnus.com Fri Dec 03 01:14:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Blandy <jimb@cygnus.com>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.cygnus.com
Subject: Re: ST(i) and MMj
Date: Fri, 03 Dec 1999 01:14:00 -0000
Message-id: <38478987.EECEEBF@cygnus.com>
References: <199911090706.CAA13120@zwingli.cygnus.com> <199911102246.RAA01846@mescaline.gnu.org> <npr9hi321d.fsf@zwingli.cygnus.com> <199911231303.IAA01523@mescaline.gnu.org> <npr9hg2a9t.fsf@zwingli.cygnus.com> <199911251715.MAA09225@mescaline.gnu.org> <npzovvc04o.fsf@zwingli.cygnus.com> <199912010821.DAA27130@mescaline.gnu.org> <npogca9tb8.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00434.html
Content-length: 1151
Jim Blandy wrote:
>
> > During that discussion I did agree that these registers should not be
> > treated as separate, but it seems we meant different things.
> > What I meant was that it is a Bad Idea to maintain separate data for
> > each one of these sets.
>
> Ah. I see what you meant now. Yes, we misunderstood each other.
>
> > But I don't see why cannot GDB _think_ about %st(X) and %mmY as being
> > separate registers while in reality they share the same data, if this
> > sharing is concealed behind REGISTER_BYTE and REGISTER_RAW_SIZE (and
> > possibly other functions/macros used to manipulate registers). What
> > are the specific problems with this scheme?
>
> Grep the sources for NUM_REGS, and look for loops that traverse the
> register set. Prove to yourself that none of these loops will break
> if register X aliases register Y. Persuade yourself that nobody in
> the future, innocent of the x86's sins, will write such a loop.
>
> I tried, but I couldn't manage it. :)
I agree with Jim. The way GDB currently resolves register names/numbers
``freaks me out''.
(Now about that REGISTER_VIRTUAL_NAME macro :-)
Andrew
From alexs@cygnus.co.uk Fri Dec 03 03:41:00 1999
From: "Alex Schuilenburg" <alexs@cygnus.co.uk>
To: "Stan Shebs" <shebs@cygnus.com>
Cc: <gdb@sourceware.cygnus.com>, "Hugo Tyson" <hmt@cygnus.co.uk>
Subject: RE: Multi-threaded debugging within GDB & eCOS
Date: Fri, 03 Dec 1999 03:41:00 -0000
Message-id: <NCBBKJPHEKGAJNNFGNBLCEMJDHAA.alexs@cygnus.co.uk>
References: <199912030305.TAA24626@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00435.html
Content-length: 4176
> GDB will "lock up". More precisely, GDB will sit quietly waiting for
> the target to do something, not realizing that the user has caused a
> deadlock by manually suspending thread A. This is as expected, since
> GDB has no way to know that the program is in this state. In
> practice, the user gets impatient, hits ^C, sees the current state,
> and goes "oh yeah, my fault" and fixes.
I figured it would.
> GDB's default behavior is to give all threads a chance to run when
> resuming, which generally prevents this kind of situation. We
> introduced the scheduler-locking flag for those cases where the user
> really really needs to lock out other threads, even if it might mean
> the thread being stepped will block.
Hugo and I had a discussion a while ago about the usefulness of this flag
and come to the conclusion that it was not, or rather the semantics of it
should be changed. Locking the scheduler is dangerous for this very reason.
You may have interrupts occuring which need to be serviced on the target
hardware and this method will lock out the service thread, and in certain
cases even crash the hardware. So you really need to have a less intrusive
method of debugging, particularly for deeply embedded real-time debugging.
The solution we came up with for eCos was something similar to what I had
done before. See below.
> (I'd be interested to know if you have workarounds for this
> fundamental problem though.)
Sort of. I wrote a debugger for Helios which was targetted at
multi-threaded non-intrusive debugging. For this I termed the phrase
"loosly coupled debugging". Essentially the target hardware (e.g. threads
not being debugged) had to keep on running, even when a bp was hit by a
thread being debugged, else the h/w would die. I had a debug agent running
on the h/w which would talk back to the debugger and let it know when a bp
was hit, when an exception occurred etc, but more importantly it would run
in conjunction with the application which was being debugged. That is, the
debugger on the host could query the agent on the target at any time to
query the status of the h/w and the status of actively running threads. You
could do a backtrace which was a "sample" where a thread on the remote app
was at when the bt command was executed, and set breakpoints within the app
while the app was still running.
More importantly I introduced the freezing and thawing of threads. This
required some support from the RTOS. If you froze a thread, the RTOS would
no longer schedule it for execution. Similarly threads were thawed to allow
them to resume. So the user would freeze only the threads which they did
not want to interact with the thread they were debugging. Naturally you
could inspect the stack etc of a frozen thread as the full register context
of the frozen thread was preserved and available to the agent, and hence the
debugger. There was no concept of ^C as you always had a command line. If
you wanted to stop the target entirely you would simply freeze all threads.
Naturally the debug agent would be exempt.
The cool thing was that you could leave the debug agent in your final app.
So you could walk up to the running h/w in the field, hook a portable to the
serial port, and attach the debugger. Hence you could query the target to
find out what it was doing, what state threads were in, and if you had the
matching source and symbol tables available, even start debugging it. Like
attaching gdb to an active process on UNIX (which is where I snarfed the
idea from).
Things were a bit more complex (aren't they always) since you could debug
the agent itself and still had to provide the ability to debug the RTOS
which was controlling everything, including the agent. So threads could
only be frozen if they were not consuming a system resource. That is,
something which the debug agent or RTOS would need to fulfill its
obligations. Of cource you could over-ride this to debug the kernel and
system calls, but in these instances the agent could fall back into a
gdb-stub mode, and the user suffered the consequences of freezing the
hardware. At least they were warned...
Cheers
-- Alex
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-12-02 22:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-11-27 18:50 -Wmissing-prototypes Andrew Cagney
1999-09-20 0:46 ` -Wmissing-prototypes Andrew Cagney
[not found] ` <37CB6DBE.2083662F@cygnus.com>
[not found] ` <199912021414.JAA16068@mescaline.gnu.org>
1999-12-02 7:42 ` -Wmissing-prototypes Andreas Jaeger
[not found] <Pine.SUN.3.91.991202192443.17848B-100000@is>
1999-12-02 22:19 ` -Wmissing-prototypes Andreas Jaeger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox