From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Fernando Nasser Cc: gdb@sourceware.cygnus.com, Andrew Cagney , taruna@redhat.com, Eric Bachalo Subject: Re: Remote protocol extension for register ranges Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5m66ufj7ii.fsf@jtc.redbacknetworks.com> References: <38D8CFA4.C3535C93@redhat.com> X-SW-Source: 2000-q1/msg00771.html >>>>> "Fernando" == Fernando Nasser writes: Fernando> Presently, the remote protocol can only read all registers Fernando> of a target. This is OK for the context registers (the ones Fernando> that are saved by the OD on a context switch) but this is a Fernando> serious limitation for machines that have lots of additional Fernando> registers. It is just not feasible to read them all at Fernando> every "g" packet. If a target has so many registers that you don't want to read them all with the "g" command packet, I believe you are going to need something similar for the "G" command packet. Otherwise, any read/modify/write operations GDB does will end up reading and writing the entire set. Fernando> I would like to add parameters to the "g" packet. Something Fernando> similar has been proposed before -- the only difference is Fernando> that I would like the parameters to be a register number or Fernando> a register number range range. You could probably get away with adding parameters to the "g" command packet --- as far as I can tell none of the sample stubs completely parse the command. But if GDB sent "g" command packet containing a register range to such stubs, it would get the entire register set. You would have to write a some sort of run time test to determine whether it handled register ranges. Adding parameters to the "G" command packet is more troublesome --- the register values immediately follow the command character. For these reasons, I recommend implementing a new set of commands which would deprecate G/g/P/p. Perhaps something like: Get Registers: y, Set Registers: Y,, But while we are adding commands, we might want to consider whether there are any other arguments we should add. One that comes to mind is a thread-id. Currently, when we want to get the registers from several threads on the target, GDB has to issue a set thread command before each store/fetch register command. If the thread-id was part of the request, it could significantly improve remote protocol performance, especially on low-bandwidth and/or high latency connections. For amusement purposes only, I've enclosed the store and fetch sections from the specification I've been writing for a replacement remote protocol. Other than the register ranges being specified by offset and length, it's pretty much the same as the above. --jtc 4.1 REGISTER FETCH input: context_t id; int offset; offset within register data int length; length of transfer output: int status; char data[]; This command may yeild unpredicable results if context has not been suspended. issues: This assumes a single flat address space for all registers. It might be convienent to have separate (but potentially overlapping) register files for integer registers, floating point registers, system registers, miscellaneous registers, etc. For example, one register file could contain the PC, FP, SP, and whatever other registers are needed on a particular architecture for GDB after a signal/exception/breakpoint event. This would solve the problem of what to return in those events. 4.2 REGISTER STORE input: context_t id; int offset; offset within register data int length; length of transfer char data[]; output: int status; This command may cause unpredictable behavior if context has not been suspended. issues: see also register fetch. 4.3 MEMORY FETCH input: addr_t address; address of transfer int length; length of transfer mode_t mode; output: int status; char data[length]; description: Returns the contents of the memory region at
through
+ . This command may yeild unpredictable results if all contexts which access this memory region have not been suspended (unless some mutual exclusion mechanism is employed). issues: should this command take a "address space" argument? This might be useful for I/O space and bus spaces. If so, should registers simply be considered a "space". issues: should this command take a context id argument as well? This might be desirable if different contexts can have different memory mappings. 4.4 MEMORY STORE input: addr_t address; address of transfer int length; length of transfer mode_t mode; char data[length]; output: int status; description: Writes data[] at
through
+ This command may cause unpredictable results if all contexts which access this memory have not been suspended (unless some mutual exclusion mechanisms is employed). issues: see also memory fetch. -- J.T. Conklin RedBack Networks >From insulaner_andi@yahoo.com Sat Apr 01 00:00:00 2000 From: Andreas Kuepper To: gdb@sourceware.cygnus.com Subject: building GDB on Cygwin fails Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000311184701.12922.qmail@web3401.mail.yahoo.com> X-SW-Source: 2000-q1/msg00675.html Content-length: 2739 Hi there, I am running a Win98 host system and installed Cygwin successfully. The building of a GCC cross compiler was also successfully for a DOS based target system using DJGPP. Now I want to install GDB on my host(on Cygwin) and build it for my DJGPP target. By using the latest GDB (gdb-20000305.tar.bz2) the configure script works fine. But when I want to build it, I get the following error message while 'make' is inside the gdb-folder : bash-2.02$ make rm -f gdb.exe gcc -g -o gdb.exe main.o libgdb.a ../bfd/libbfd.a ../readline/libreadline.a ../opcodes/libopcodes.a ./../intl/libintl.a ../libiberty/libiberty.a `if test -r ../libtermcap/libtermcap.a; then echo ../libtermcap/libtermcap.a; else echo -ltermcap; fi` -lm ../libiberty/libiberty.a -luser32 libgdb.a(stack.o): In function `frame_info': /djgpp/cross/gdb2000/gdb/../../gdb-20000305/gdb/stack.c:952: undefined reference to `sigtramp_saved_pc' libgdb.a(blockframe.o): In function `file_frame_chain_valid': /djgpp/cross/gdb2000/gdb/../../gdb-20000305/gdb/blockframe.c:48: undefined reference to `sigtramp_saved_pc' libgdb.a(blockframe.o): In function `get_prev_frame': /djgpp/cross/gdb2000/gdb/../../gdb-20000305/gdb/blockframe.c:479: undefined reference to `sigtramp_saved_pc' libgdb.a(blockframe.o): In function `generic_file_frame_chain_valid': /djgpp/cross/gdb2000/gdb/../../gdb-20000305/gdb/blockframe.c:1276: undefined reference to `sigtramp_saved_pc' /djgpp/cross/gdb2000/gdb/../../gdb-20000305/gdb/blockframe.c:1279: undefined reference to `sigtramp_saved_pc' /cygdrive/c/CYGNUS/CYGWIN~1/H-I586~1/BIN/../lib/gcc-lib/i586-cygwin32/2.95.2/../../../libtermcap.a(tputs.o): In function `tputs': /home/noer/src/b20/comp-tools/devo/libtermcap/tputs.c:72: undefined reference to `_ctype_' /home/noer/src/b20/comp-tools/devo/libtermcap/tputs.c:75: undefined reference to `_ctype_' /home/noer/src/b20/comp-tools/devo/libtermcap/tputs.c:80: undefined reference to `_ctype_' /cygdrive/c/CYGNUS/CYGWIN~1/H-I586~1/BIN/../lib/gcc-lib/i586-cygwin32/2.95.2/../../../libtermcap.a(termcap.o): In function `tgetent': /home/noer/src/b20/comp-tools/devo/libtermcap/termcap.c:251: undefined reference to `_ctype_' /cygdrive/c/CYGNUS/CYGWIN~1/H-I586~1/BIN/../lib/gcc-lib/i586-cygwin32/2.95.2/../../../libtermcap.a(getcap.o): In function `cgetnext': /home/noer/src/b20/comp-tools/devo/libtermcap/getcap.c:686: undefined reference to `_ctype_' collect2: ld returned 1 exit status make: *** [gdb.exe] Error 1 bash-2.02$ I really don't know where to search for the fault ***[gdb.exe] Error Thank you for your help !! Andreas Kuepper __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: memory region attribute CLI Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003211819.NAA12438@indy.delorie.com> References: <5mr9dd5dlt.fsf@jtc.redbacknetworks.com> <200003160944.EAA01842@indy.delorie.com> <5mem9avs45.fsf@jtc.redbacknetworks.com> <5m3dplwjri.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00760.html Content-length: 585 > >>>>> "jtc" == J T Conklin writes: > jtc> Yes, I guess it has been a while, hasn't it. > jtc> > jtc> Start at: > jtc> http://sourceware.cygnus.com/ml/gdb/1999-q4/msg00168.html > > No comments? Sorry, you are right. I think this is a very useful idea. But as far as I understand, the information managed by the code you posted needs to be consulted by other GDB commands, right? I don't see any code that does that yet. I'm not saying that this somehow invalidates your code and descriptions, I just want to be sure I'm not missing anything important. >From jsm@cygnus.com Sat Apr 01 00:00:00 2000 From: Jason Molenda To: Assar Westerlund Cc: gdb@sourceware.cygnus.com Subject: Re: anoncvs errors? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000209091801.A1546@cygnus.com> References: <5l7lgez651.fsf@assaris.sics.se> X-SW-Source: 2000-q1/msg00192.html Content-length: 465 On Wed, Feb 09, 2000 at 05:34:50PM +0100, Assar Westerlund wrote: > Hi, I'm getting this error trying to use anonymous CVS to > :pserver:anoncvs@anoncvs.cygnus.com:/cvs/gdb. > > Sorry, you don't have read/write access to the history file /cvs/gdb/CVSROOT/history > Permission denied The repository has moved, use :pserver:anoncvs@anoncvs.cygnus.com:/cvs/src (although you shouldn't have gotten an error with the old repo quite yet. I will look in to it.) Jason >From jimb@cygnus.com Sat Apr 01 00:00:00 2000 From: Jim Blandy To: gdb@sourceware.cygnus.com Subject: [cygnus.gcc] dwarfdump Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: X-SW-Source: 2000-q1/msg00363.html Content-length: 675 This may be of interest to anyone working on GDB and using Dwarf 2 debugging information. ------- Start of forwarded message ------- From: jason@cygnus.com (Jason Merrill) Newsgroups: cygnus.gcc Subject: dwarfdump Date: 21 Feb 2000 11:10:17 -0800 Organization: Cygnus Solutions news/mail gateway Message-ID: <200002211910.LAA17403.cygnus.gcc@yorick.cygnus.com> To: gcc-local@cygnus.com FWIW, the SGI dwarf2 printing utility, dwarfdump, is available in http://reality.sgi.com/davea/libdwarf1999Dec14.tar.gz I've built it for Solaris (~jason/.bin/sparc-sun-solaris2.5/dwarfdump) and linux (/usr/unsupported/bin/dwarfdump). Jason ------- End of forwarded message ------- >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: Moving Linux-specific stuff out of i386-tdep.c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003091349.IAA19958@indy.delorie.com> References: <200003082121.e28LLRu05681@delius.kettenis.local> <1000308222742.ZM8876@ocotillo.lan> <38C7AA6D.5465C647@cygnus.com> X-SW-Source: 2000-q1/msg00644.html Content-length: 107 > The 8.3 uniqueness rule definitly still applies. Should I post a list of files which violate that rule? >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: jimb@cygnus.com Cc: hjl@lucon.org, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Problems with hardware watchpoint on ia32. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003312323.SAA07185@indy.delorie.com> References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> <200003091210.HAA19857@indy.delorie.com> <200003221806.NAA14225@indy.delorie.com> X-SW-Source: 2000-q1/msg00849.html Content-length: 905 > > I seem to be unable to reproduce the problem, at least in a C program: > > whenever I say "watch foo == bar" (where foo and bar are structs), GDB > > curses thusly: > > > > Structure has no component named operator==. > > > > Am I missing something? > > As Michael points out, structure comparison is broken. But that > doesn't change my original point --- that it's perfectly legitimate to > have `struct value' objects representing structures, which should be > watched in their entirety. The current sources do support watching an entire struct, the patches I sent (and Michael commited) have special provisions for this case. I asked for an example because I want to look into the problem you were describing and fix it. Do you have any other case where this problem could happen? If every instance of such a situation is equally broken, then the users won't miss this functionality ;-). >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: annotate.texi Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003091254.HAA19889@indy.delorie.com> References: <38C74298.B562FDD1@cygnus.com> <200003070832.DAA14451@indy.delorie.com> X-SW-Source: 2000-q1/msg00640.html Content-length: 1098 > > Is there any reason why annotate.texi shouldn't be @include'd by > > gdb.texinfo and be part of the manual? Right now, "set annotate" is > > not documented at all, and annotate.texi seems to be just what the > > doctor ordered... > > I just wonder if we want to encourage its use :-) Any user who types "gdb --help" will see the --annotate switch advertised, and will want to know what that does. Without annotate.texi in the manual, this switch cannot be documented properly. The same goes for the "set annotate" command. I think undocumented features should be generally avoided. Here's a case in point. I'm going through the test suite trying to make sure the DJGPP version passes all the tests. When I bumped into the test which tests annotations, I wanted to know what does that command do. Naturally, I looked it up in gdb.info, and when that failed in gdbint.info. You can guess what I found ;-). In other words, undocumented features in the long run haunt maintainers as well. If we want to discourage use of --annotate, we can say that explicitly in the manual. Comments? >From fnasser@redhat.com Sat Apr 01 00:00:00 2000 From: Fernando Nasser To: Andrew Cagney Cc: Grant Edwards , Fernando Nasser , gdb@sourceware.cygnus.com Subject: Re: RDI target broken in 000215 snapshot Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38B69A2A.ED2DC6F3@redhat.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> <38B59CE1.4CFA7F1E@cygnus.com> <20000224152638.A2092@visi.com> <38B61CF6.B4F80802@cygnus.com> X-SW-Source: 2000-q1/msg00418.html Content-length: 962 Andrew Cagney wrote: > > It's more a question of should the endianess have changed between > releases or should it have been little-endian anyway. Not my problem > :-) > I inherited this one :-) But you are right, this will at least require an entry in the NEWS, as it alters some previous behavior. *If* the arm users in the list decide that the default should be little-endian. It does seem reasonable and if the file command straights it out, only the load users would have to care (but they are more aware of these issues, and can always have the set endian on their .gdbinit). It is a shame that Angel is so buggy. The return code should appropriately indicate the endianess of the target -- it would be a nice feature to use :-( -- Fernando Nasser Red Hat, Inc. - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 >From leisner@rochester.rr.com Sat Apr 01 00:00:00 2000 From: "Marty Leisner" To: shebs@apple.com Cc: gcc@gcc.gnu.org, gdb@sourceware.cygnus.com, leisner@rochester.rr.com Subject: Re: Should GCC tell GDB about its optimizations? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003040446.XAA04330@rochester.rr.com> References: <38C051C3.260D666B@apple.com> X-SW-Source: 2000-q1/msg00533.html Content-length: 3255 Yes...!!! I proposed something like this years ago...I almost hacked up gcc to put this in (I think I started...) It is incredibly useful in the real world to encapsulate what compiler flags were used in the binary (essentially the gcc command line with preprocessor flags). I just compiled a trivial C program with -O3 to see.. The .s file has .ident "GCC: (GNU) 2.95.2 19991024 (release)" Is there a way for nm to decode this? (strings can show it, but its pretty meaningless in the binary). For example: ... GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) GCC: (GNU) 2.95.2 19991024 (release) GCC: (GNU) 2.95.2 19991024 (release) GCC: (GNU) 2.95.2 19991024 (release) GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) .... I don't know how to take apart elf binaries off the top of my head, but I assume there is information someplace encoded to match this up with specific files. gdb doesn't have to warn, but you should be able to use a tool to figure this out. Marty Leisner Stan Shebs writes on Fri, 03 Mar 2000 15:58:59 PST > I'm sure this subject has come up before, but I don't remember any > consensus... > > In the process of finishing Mac OS X, Apple has hundreds of engineers > beating on GCC and GDB every day. The system has literally hundreds > of subcomponents; everything from the kernel to speech output to Hebrew > font support (sort of like a Linux system preloaded with everything > you can find on freshmeat :-) ). By default, everything is built with > optimization turned on. While an engineer can turn off optimization > for a specific bit of code, it's not practical to build an entire system > with optimization turned off. So in practice any single program consists > of a combination of optimized and unoptimized code. > > Ideally of course, GCC would issue lots of amazingly detailed debug info, > and GDB would use it to reconstruct and report program state just as the > programmer expects to see it. But today, the result is just lame; hackers > trying to debug get lots of squirrelly behavior from GDB. The problem is > that they don't know whether the randomness is due to bugs in the program, > or to the effect of the optimizer. So the suggestion came up to have GCC > issue debug info stating what optimizations have been applied to a file, > and to have GDB report that information per-function, so that users could > lower their expectations appropriately. > > Although my first reaction was to say "bleah", upon reflection I wondered > if I was too easily dismissing the concerns of real users of the tools. > This sort of thing routinely confuses users; even with years of GNU > experience, I still find myself being caught by surprise because I've > forgotten that part of the code was optimized. A simple warning from the > debugger would have saved me some time and trouble. > If there's consensus that this would be a worthwhile addition, I'll > work up a specific design and publish it. > > Stan