> I'm trying to add some indexing whenever I can. But I suggest that > every manual patch be scrutinized for appropriate index entries Sounds like the voice of someone volunteering to do some scrutinization ;-). Believe me, "people sending in lots of manual patches which never get merged" just hasn't been a problem on any free software project I've worked on. Having Stan as the documentation maintainer is a good thing too, because we are willing to hurt him if he slacks off :-). From toddpw@windriver.com Sat Apr 01 00:00:00 2000 From: Todd Whitesel To: akale@veritas.com (Amit S. Kale) Cc: toddpw@windriver.com (Todd Whitesel), kingdon@redhat.com (Jim Kingdon), akale@veritas.com, kettenis@wins.uva.nl, gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: Regression caused by elfread.c patch Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002152007.MAA08037@alabama.wrs.com> References: <00021514224700.31608@fermat.vxindia.veritas.com> X-SW-Source: 2000-q1/msg00299.html Content-length: 2051 > I guess gdb first prepares text, data, bss segments and following code > bfd/section.c:bfd_make_section_anyway(): > newsect->index = abfd->section_count++; > indicates that section->index contains SECT_OFF_* codes when segments are > loaded. This may not have been designed this way, but it seems to be that way. Yes, this looks like a desperate attempt to deal with the fundamental numbering conflict that currently exists. Any time stabs are read, much of GDB assumes that ANOFFSET takes SECT_OFF_* values, even in cases where you'd expect it to take BFD section indices. So anyone actually attempting to use BFD indices for real is plagued by subtle bugs. > Using sym->section->index is not right for segments that are not text or data > segments. Using sym->section->index should be all right for data segments. It depends on the path through the *_symfile_offsets code that is taken. symtab.h explicitly claims that the section numbers in ANOFFSET are "file-type-dependent" but this is largely ignored by the rest of GDB. > I suggest following patch. I have verified that the vfprintf problem reported > by Mark does not appear with this patch. I haven't tested it with test suite. I guarantee you it won't completely solve the problem. But if the test suite uses fully-linked programs, it will end up passing the tests anyway because ANOFFSET returns 0 for all sections when a file is fully linked. > > However, so few configurations (read: vxWorks and ??) actually use different > > offsets for, say, SECT_OFF_TEXT and SECT_OFF_DATA, that no one notices the > > problems with it. (We read relocatable .o files too, which is also rare.) > > It won'd be rare when gdb will be used by more people to debug linux kernel > modules. I hope you've got patches to symbol_file_add() and *_symfile_offsets to accept more than one address offset for the section_offsets->offsets array. If not, then any section loaded independently from .text is going to have mucho problems being relocated by GDB. -- Todd Whitesel toddpw @ windriver.com From grante@visi.com Sat Apr 01 00:00:00 2000 From: Grant Edwards To: Fernando Nasser Cc: 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: <20000224133238.A723@visi.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> X-SW-Source: 2000-q1/msg00402.html Content-length: 1495 On Thu, Feb 24, 2000 at 02:12:18PM -0500, Fernando Nasser wrote: > > When I download code with the "load" command, the byte order of > > the data gets flipped -- it ends up in little-endian order > > (it's big-endian in the file, and I need it to stay that way > > when it is downloaded). Downloading with a patched 4.18 doesn't > > have this problem. > > > Grant, > > What compiler, in what host and with which parameters did you > generate your executable file? $ uname -a Linux grante.comtrol.com 2.2.12-20 #1 Mon Sep 27 10:25:54 EDT 1999 i586 unknown $ arm-elf-gcc --version 2.95.2 $ arm-elf-as --version GNU assembler 991018 $ make arm-elf-as --gstabs -EB -m arm7tdmi -amhlsnd=memconfigR10_S0_D100.lst -o memconfigR10_S0_D100.o memconfigR10_S0_D100.s arm-elf-gcc -g -mcpu=arm7tdmi -fverbose-asm -mbig-endian -Wl,-Map,memconfigR10_S0_D100.map -nostartfiles -o memconfigR10_S0_D100 memconfigR10_S0_D100.o -T./memconfig.ld -nostdlib libgcc.a > Is it the same one you can successifuly load with the patched 4.18? Yes. > In both cases you are loading the program into the AEB board, right? No. I'm loading to custom hardware (big-endian), but I verified that the same thing happens with the Samsung SNDS eval board (also big-endian hardware). I've used the EPI Jeeni (via ethernet) and the ARM Embedded ICE (via serial port) and had the same results. > I forgot, which host are you running gdb in? Linux, Solaris, Cygwin? Linux (same as above). -- Grant Edwards grante@visi.com From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: "H . J . Lu" Cc: Stan Shebs , gdb-patches@sourceware.cygnus.com, GDB Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> References: <20000307134103.A20533@valinux.com> <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> X-SW-Source: 2000-q1/msg00575.html Content-length: 334 >>>>> "hjl" == H J Lu writes: hjl> 2000-03-07 H.J. Lu hjl> hjl> * gdb-regex.h: New. Include for glibc 2 and include hjl> "gnu-regex.h" otherwise. If we follow the naming convention we have been using, gdb-regex.h should be gdb_regex.h. --jtc -- J.T. Conklin RedBack Networks From jimb@cygnus.com Sat Apr 01 00:00:00 2000 From: Jim Blandy To: gdb@sourceware.cygnus.com Subject: Try out the patch database Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002292134.QAA10095@zwingli.cygnus.com> X-SW-Source: 2000-q1/msg00450.html Content-length: 858 Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and let me know what you think. I'd like to incorporate the text of that page itself into the main GDB page, http://sourceware.cygnus.com/gdb/ . contribute.html refers to three new pages: - patch-db.html, which is supposed to be everything a new contributor needs to know to add a patch to the patch database. - patch-checklist.html, a checklist for submitting patches via E-mail. Originally, I was going to do a template, but it seems like GNATS will do everything that's important automatically, so I don't think a template offers much benefit over simple instructions. - assigning.html, a page explaining the copyright situation, and directing people to talk to me. Eventually, of course, we'll want a role mail address for this, but I want to get things going quickly. From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Jim Kingdon , gdb@sourceware.cygnus.com Subject: Re: Status Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A48A0D.D7AE28C2@apple.com> References: <38A34041.B443DAFB@apple.com> <38A46C5C.F8301644@apple.com> X-SW-Source: 2000-q1/msg00234.html Content-length: 370 Stan Shebs wrote: > There's some kind of Mach layer underneath, 2.5 I think, [...] Ooops, should have checked http://www.apple.com/macosx/inside.html where this is described for everybody: The system’s kernel [...] is based on Mach 3.0 from Carnegie-Mellon University and FreeBSD 3.2 (derived from the University of California at Berkeley’s BSD 4.4-Lite) Stan From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: "Gabor Z. Papp" Cc: gdb@sourceware.cygnus.com Subject: Re: gdb cvs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BDE5F9.49AD7232@cygnus.com> References: <200003011940.e21Je9528423@mail.gzp.org.hu> <20000302032052.L17285@gzp.org.hu> X-SW-Source: 2000-q1/msg00484.html Content-length: 324 "Gabor Z. Papp" wrote: > > | cvs checkout: authorization failed: server anoncvs.cygnus.com rejected access > > What is with the cvs access? Same problem as the BINUTILS repository - it's been moved. Both GDB and BINUTILS are drawn from a common CVS repository. Check http://sourceware.cygnus.com/gdb/ enjoy, Andrew From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: new version of rproxy Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: X-SW-Source: 2000-q1/msg00131.html Content-length: 155 > I put a new rproxy-0.6 to my web site > http://www.std.com/qqi/labslave/rproxy.html Cool! I've added a link from http://sourceware.cygnus.com/gdb/ From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com Subject: Re: Dependence on config.status Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C220BE.44922A6@cygnus.com> References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> <200003021007.FAA04124@indy.delorie.com> <38C0ACF2.C00719B0@cygnus.com> <200003050737.CAA10121@indy.delorie.com> X-SW-Source: 2000-q1/msg00545.html Content-length: 1020 Eli Zaretskii wrote: > > > Eli Zaretskii wrote: > > > > > > > Well, if memory serves, if you re-ran configure in such a way that > > > > tm.h started linking to a different file, then the config.status > > > > dependency was the only way to force a rebuild. > > > > > > How about adding some #define to config.h that would also change when > > > this happens? > > > > Such as the names of the tm, xm and nm files? > > Yes, that's what I had in mind. Since the configure scripts already > knows the names of those files, it could put them into config.h. Well I've long had in mind a ``maint build-info'' command that printed out things like: tm/xm/hm.h the --host/target/build tupples the compiler the path to the source tree the build date the user/machine Assuming your suggestion works (JimK doesn't find more technical flaws (1) :-) A change putting tm/xm/hm into config.h is ok with me :-) Andrew (1) I think changing tm/xm/nm happens sufficiently often for it to be dangerous to not force a rebuild. From Guenther.Grau@marconicomms.com Sat Apr 01 00:00:00 2000 From: Guenther Grau To: gdb@sourceware.cygnus.com Subject: Re: gdb and iso-c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DB7FF7.E3AFDE79@marconicomms.com> References: <200003241301.OAA04488@mail.macqel.be> X-SW-Source: 2000-q1/msg00796.html Content-length: 1036 Hi, Philippe De Muyter wrote: > Up to some years ago, gdb could be compiled by a K&R C compiler. > Now, it can not anymore, and the change seems to be deliberate. Well, you have to move forward, even if you don't see it as a step forwad ;-) > It seems to me that the freedom of the gdb users is now restricted compared > to the previous versions because of the need of an ISO-C compiler instead > of any C compiler to compile it. > > And I do not understand why the same reasons that apply to binutils and gcc > do not hold for gdb. gdb, because it is better than the debugger you get > with your operating system, is needed to bootstrap the installation of > gas, gld, or gcc in the likely case that not everything works well > the first time. All major operating systems I know come with a reasonable modern iso-c compiler (or at least you can get one for it). And even if this weren't the case, you can always crosscompile gdb on a different platform (This feature needs more testing anyways ;-) Just my 0,02 EUR, Guenther From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: gdb@sourceware.cygnus.com Cc: ezannoni@cygnus.com Subject: Buffering problems with "gdb < foo" Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003050850.DAA10185@indy.delorie.com> X-SW-Source: 2000-q1/msg00544.html Content-length: 1150 A comment in event-top.c (inside the change_line_handler function) says this: /* NOTE: this operates on input_fd, not instream. If we are reading commands from a file, instream will point to the file. However in async mode, we always read commands from a file with editing off. This means that the 'set editing on/off' will have effect only on the interactive session. */ However, running "gdb < foo" seems to contradict this: I put a breakpoint in gdb_readline2, and it is never hit. Am I missing something? The problem with this is that if the file `foo' includes a command which needs a confirmation, the call to fgetc in query will eatup lots of characters which will never again be seen by the event loop. In my case, fgetc read all the file (it was small), so GDB hit EOF and exited. I can prevent this from happening by putting "set editing off" in the input file. Invoking GDB with --noasync also solves the problem. Does this work on Unix? If so, it would make this a DJGPP-specific problem. If this is not DJGPP-specific, then I think _initialize_event_loop should turn editing off if input_fd is not a tty. From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000 From: Pierre Muller To: gdb@sourceware.cygnus.com Subject: Re: Updated MAINTAINERS file - work in progress Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002111033.LAA29442@cerbere.u-strasbg.fr> X-SW-Source: 2000-q1/msg00221.html Content-length: 434 At 21:33 10/02/00 -0800, you wrote: >> Andrew Cagney ac131313@cygnus.com? >> Stan Shebs shebs@cygnus.com? Wouldn't it be much more logical to have aliases here ? Andrew.Cagney@sourceware.cygnus.com or even better Andrew.Cagney@gdb.fsf.org ??? Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 From hanymorcos@yahoo.com Sat Apr 01 00:00:00 2000 From: Hany Morcos To: Hany Morcos , gdb@sourceware.cygnus.com Subject: Re: Debugging a constructor Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000225003041.21219.qmail@web3204.mail.yahoo.com> X-SW-Source: 2000-q1/msg00413.html Content-length: 686 Got it thank you --- Hany Morcos wrote: > > > How do I print the variable values inside > a constructor? > > I can't use this... Because doesn't exist yet.. > The object hasn't been constructed... > > Then how do I print the value of x?? > > class y{ > > public: > y(int* x) {x = > coreDumpAndGenerateManyHeadaches(); // print x > inside > gdb } ; > }; > > > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: `long double' support for ix86 targets Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003031531.e23FV8T00285@delius.kettenis.local> X-SW-Source: 2000-q1/msg00523.html Content-length: 5450 Hi, Kevin's changes to findvar.c:extract_floating() and store_floating() together with some further analysis have convinced me that for all but one ix86 targets 96-bit long doubles of type &floatformat_i387_ext are the right thing. This would give most of the ix86 targets instant support for long doubles. It also gives us the opportunity to remove some ugly bits introduced by people who tried to hack around the current limitations. Here are some personal notes I made about this: Support for `long double' ------------------------- The majority of i386 targets in GCC have a `long double' that is 96 bits wide (of which only 80 bits are used, the rest is padding). In fact the only exception is OSF/1, where `long double' is equivalent to `double' and has only 64 bits. This length of 96 bits is also used in the debugging information generated by the compiler. The origional i386 System V ABI specification doesn't say anything about `long double', but the new (draft) IA-64 System V ABI specification uses a `long double' of 96 bits for things running in 32-bit mode. I guess that 32-bit mode is supposed to be provided for compatible with IA-32, this implies that 96 bits is supposed to be the standard. Therefore, `config/i386/tm-i386.h' should define: #define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext #define TARGET_LONG_DOUBLE_BITS 96 Targets such as OSF/1 can override this. If we do the above, we can make the default "virtual" type of the FPU registers `builtin_type_long_double'. A lot of the Linux cruft for dealing with `long double' could be removed. I intend to check in the following patch in a week or two, but since this change affects most of the ix86 targets, I'd like to give people the opportunity to object. Mark 2000-03-02 Mark Kettenis * config/i386/tm-i386.h (TARGET_LONG_DOUBLE_FORMAT): Define as &floatformat_i387_ext. (TARGET_LONG_DOUBLE_BITS): Define as 96. (REGISTER_VIRTUAL_TYPE): Change type for FPU registers to `builtin_type_long_double'. (REGISTER_CONVERT_TO_VIRTUAL): Simply copy over the data, and pad with zeroes. (REGISTER_CONVERT_TO_RAW): Simply copy over the significant data. (i387_to_double, double_to_i387): Remove prototypes. Index: config/i386/tm-i386.h =================================================================== RCS file: /cvs/src/src/gdb/config/i386/tm-i386.h,v retrieving revision 1.2 diff -u -p -r1.2 tm-i386.h --- config/i386/tm-i386.h 2000/02/29 13:28:24 1.2 +++ config/i386/tm-i386.h 2000/03/03 15:00:49 @@ -1,5 +1,5 @@ /* Macro definitions for GDB on an Intel i[345]86. - Copyright (C) 1995, 1996 Free Software Foundation, Inc. + Copyright (C) 1995, 1996, 2000 Free Software Foundation, Inc. This file is part of GDB. @@ -28,6 +28,19 @@ struct type; #define TARGET_BYTE_ORDER LITTLE_ENDIAN +/* The format used for `long double' on almost all i386 targets is the + i387 extended floating-point format. In fact, of all targets in the + GCC 2.95 tree, only OSF/1 does it different, and insists on having + a `long double' that's not `long' at all. */ + +#define TARGET_LONG_DOUBLE_FORMAT &floatformat_i387_ext + +/* Although the i386 extended floating-point has only 80 significant + bits, a `long double' actually takes up 96, probably to enforce + alignment. */ + +#define TARGET_LONG_DOUBLE_BITS 96 + /* Used for example in valprint.c:print_floating() to enable checking for NaN's */ @@ -229,7 +242,7 @@ extern int i386_register_virtual_size[]; #define REGISTER_VIRTUAL_TYPE(N) \ (((N) == PC_REGNUM || (N) == FP_REGNUM || (N) == SP_REGNUM) \ ? lookup_pointer_type (builtin_type_void) \ - : IS_FP_REGNUM(N) ? builtin_type_double \ + : IS_FP_REGNUM(N) ? builtin_type_long_double \ : IS_SSE_REGNUM(N) ? builtin_type_v4sf \ : builtin_type_int) @@ -239,25 +252,22 @@ extern int i386_register_virtual_size[]; that SSE registers need conversion. Even if we can't find a counterexample, this is still sloppy. */ #define REGISTER_CONVERTIBLE(n) (IS_FP_REGNUM (n)) - -/* Convert data from raw format for register REGNUM in buffer FROM - to virtual format with type TYPE in buffer TO. */ -extern void i387_to_double (char *, char *); +/* Convert data from raw format for register REGNUM in buffer FROM to + virtual format with type TYPE in buffer TO. In principle both + formats are identical except that the virtual format has two extra + bytes appended that aren't used. We set these to zero. */ #define REGISTER_CONVERT_TO_VIRTUAL(REGNUM,TYPE,FROM,TO) \ -{ \ - double val; \ - i387_to_double ((FROM), (char *)&val); \ - store_floating ((TO), TYPE_LENGTH (TYPE), val); \ -} - -extern void double_to_i387 (char *, char *); - -#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \ -{ \ - double val = extract_floating ((FROM), TYPE_LENGTH (TYPE)); \ - double_to_i387((char *)&val, (TO)); \ -} + { \ + memset ((TO), 0, TYPE_LENGTH (TYPE)); \ + memcpy ((TO), (FROM), FPU_REG_RAW_SIZE); \ + } + +/* Convert data from virtual format with type TYPE in buffer FROM to + raw format for register REGNUM in buffer TO. Simply omit the two + unused bytes. */ +#define REGISTER_CONVERT_TO_RAW(TYPE,REGNUM,FROM,TO) \ + memcpy ((TO), (FROM), FPU_REG_RAW_SIZE) /* Print out the i387 floating point state. */ #ifdef HAVE_I387_REGS From msnyder@cygnus.com Sat Apr 01 00:00:00 2000 From: Michael Snyder To: "H . J . Lu" Cc: Mark Kettenis , gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A revised patch for dlclose Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C69870.709F@cygnus.com> References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local> <20000307170321.A884@lucon.org> <200003080119.e281Jul00524@delius.kettenis.local> <20000307173547.A1068@lucon.org> X-SW-Source: 2000-q1/msg00610.html Content-length: 1507 H . J . Lu wrote: > > On Wed, Mar 08, 2000 at 02:19:56AM +0100, Mark Kettenis wrote: > > Date: Tue, 7 Mar 2000 17:03:21 -0800 > > From: "H . J . Lu" > > Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com > > Content-Type: text/plain; charset=us-ascii > > > > > HJ, please stop wasting your time pushing this patch. The patch has > > > several bad points, that you cannot fix without considerable changes > > > to the way solib.c handles and caches the link map. > > > > I just pointed out gdb needed to check the unloaded DSOs when handling > > the BPSTAT_WHAT_CHECK_SHLIBS and BPSTAT_WHAT_CHECK_SHLIBS_RESUME_FROM_HOOK > > events. It is a serious bug to me and it should be fixed in 5.0. I > > don't care how it is fixed. > > > > But I, and I hope most of the other GDB maintainers, do care how it is > > fixed! > > That is fine with me as long as it is fixed in 5.0. There is no excuse > not to get gdb to work with dlclose. "I don't like the way it fixes the > bug" doesn't count unless you can provide a different approach. I > think it is unreasonable to have a perfect fix for every bug. We can > work a better one after 5.0 if we don't have the time now. I'm sorry, but I have to disagree. I'm not addressing your patch in particular, but there are many "fixes" that are worse than no fix at all. In fact, GDB is full of them, to our (the maintainers) daily regret. There is never time to fix it right the second time. Michael From hjl@lucon.org Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: Michael Snyder Cc: Mark Kettenis , gdb@sourceware.cygnus.com Subject: Re: lin-thread cannot handle thread exit Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000307161609.B485@lucon.org> References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> X-SW-Source: 2000-q1/msg00574.html Content-length: 527 On Tue, Mar 07, 2000 at 03:27:48PM -0800, Michael Snyder wrote: > I appreciate your helping to find problems with it, and > I'd like to know what else in the code you regard as a > "loose end". One of my problems is that I'm not really > an experienced writer of multi-threaded apps -- I'm just > the person on the GDB team with the most experience with > GDB multi-thread debugging. There are 6 multi-thread examples under linuxthreads in glibc 2. They will be built when you do "make check". Play with them in gdb. H.J. From jtc@redback.com Sat Apr 01 00:00:00 2000 From: jtc@redback.com (J.T. Conklin) To: Quality Quorum Cc: gdb@sourceware.cygnus.com Subject: Re: Z-protocol errors and limts Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5mln5btbmy.fsf@jtc.redbacknetworks.com> References: X-SW-Source: 2000-q1/msg00064.html Content-length: 1524 >>>>> "Quality" == Quality Quorum writes: Quality> I have a few questions related to Z-protocol on implmentation Quality> on the stub side: Quality> Quality> 1. How many soft break point has to be supported ? Quality> Quality> 2. How stub tells gdb that it run out of soft break points ? Quality> Quality> 3. If stub supports soft break points but does not support Quality> hw (or some of hw break points), how it tells gdb about it? You point out weaknesses in the Z/z specification. In the debug stub I wrote, I reserved 32 nodes to store breakpoints of all types and returned a 'EXX' code on all failures (out of breakpoint nodes, unable to insert breakpoint, etc.). I picked 32 breakpoints out of thin air. Based on my experiences, 32 seemed like more than enough. And if it turned out too be too small, I could always re-compile the debug agent with a larger number. When my stub only supported software breakpoints, it returned a 'EXX' code for hardware breakpoint and watchpoints. GDB's remote.c handles such a response as an error (ie. remote_insert_watchpoint(), etc. will return -1), but I'm not sure this will result in an error message a user will be able to interpret correctly In retrospect, I should have given unique error codes for each possible error so that GDB could handle errors more inteligently. I'm addressing this, and many other shortcomings, in a replacement protocol I've been designing the last month or so. --jtc -- J.T. Conklin RedBack Networks From grante@visi.com Sat Apr 01 00:00:00 2000 From: Grant Edwards To: leedh Cc: gdb@sourceware.cygnus.com Subject: Re: Question..... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000329094518.C17092@visi.com> References: <38E1B5BA.C555471B@cs.hongik.ac.kr> X-SW-Source: 2000-q1/msg00836.html Content-length: 705 On Wed, Mar 29, 2000 at 04:50:19PM +0900, leedh wrote: > Now, We are willing to connect cygnus GNU debugger toolkit(host > system-window NT) to angel debugger on EBSA-285 Board(target > system-strongArm). > > But, cygnus debugger isn't connectted to target system. You're trying to use gdb to talk to the Angel ROM monitor to debug ARM software, right? And you can't get gdb to talk to the Angel monitor? 1) Make sure you have a current snapshot of gdb -- something less than two months old. Older versions of gdb don't handle RDI/ADP as well. 2) What exactly happens when you tell gdb to coneect to the Angle ROM monitor using the "target rdi" command? -- Grant Edwards grante@visi.com From Guenther.Grau@marconicomms.com Sat Apr 01 00:00:00 2000 From: Guenther Grau To: gdb@sourceware.cygnus.com Subject: Re: Try out the patch database Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BD61EF.81A4E3C6@marconicomms.com> References: <200002292134.QAA10095@zwingli.cygnus.com> <1000229221310.ZM16579@ocotillo.lan> X-SW-Source: 2000-q1/msg00476.html Content-length: 602 Hi, > > > Take a look at http://sourceware.cygnus.com/gdb/contribute.html , and > > > let me know what you think. I have a few comments on this. First of all: great to have a bug database online! Second, why is the category named gdb-patches instead of gdb? Is it not intended for people to report bugs? Is it only for patches? Third, (but not very important) why do you use persistant cookies? I don't like cookies und usually disable them, but I could live with session cookies, if you really insist on them. But persistent cookies that last for a month are not what I like. Thanx, Guenther From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: Objective-C patches? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <38CF0958.DCEDD532@doc.com> <38D5B417.64A47BC5@cygnus.com> X-SW-Source: 2000-q1/msg00744.html Content-length: 272 > I can't speak for Apple so don't believe what follows ... For more background see: http://slashdot.org/articles/00/03/17/1656240.shtml http://webx.lists.apple.com/?13@222.lE3famDWjDu^2@.ee90f2e If anyone wants to help, I'm sure there are ways to do that :-). From assar@sics.se Sat Apr 01 00:00:00 2000 From: Assar Westerlund To: gdb@sourceware.cygnus.com Subject: anoncvs errors? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <5l7lgez651.fsf@assaris.sics.se> X-SW-Source: 2000-q1/msg00191.html Content-length: 216 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 /assar From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: scottb@netwinder.org Cc: msnyder@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Problems with changes to linux-thread.c, gdb_wait.h Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003192243.e2JMhPe00619@delius.kettenis.local> References: <38D2A8E2.755D235D@netwinder.org> X-SW-Source: 2000-q1/msg00739.html Content-length: 482 Date: Fri, 17 Mar 2000 16:51:30 -0500 From: Scott Bambrough Your changes listed below are causing me two problems on ARM with glibc 2.1.3. They're not exactly *my* changes :-(. 2000-03-17 Mark Kettenis * gdb_wait.h: add definitions of WSETSTOP and WSETEXIT for Linux. * linux-thread.c: Use WSETSTOP instead of W_STOPCODE. Michael, if you rework a patch a bit, could you please put your own name on it? Mark From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Richard Chan Cc: gdb@sourceware.cygnus.com Subject: Re: GDB supporting namespace std? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A7E3AD.5BE72E9C@cygnus.com> References: X-SW-Source: 2000-q1/msg00263.html Content-length: 401 Chan Shih-Ping wrote: > > Does GDB support the use of namespace std::, > code compiled with -fhonor-std (and an > appropriately compiled libgcc.a) and using > std::string s. > > However attempts at using > print s.size > > gives messages like > Couldn't find method string::size() Given that no one has responded, I'd suspect the answer to be no. It sounds like a good problem to persue. Andrew From shebs@apple.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Philippe De Muyter Cc: gdb@sourceware.cygnus.com Subject: Re: gdb and iso-c Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38DBB76D.65C58273@apple.com> References: <200003241301.OAA04488@mail.macqel.be> X-SW-Source: 2000-q1/msg00799.html Content-length: 1525 Philippe De Muyter wrote: > > Up to some years ago, gdb could be compiled by a K&R C compiler. > Now, it can not anymore, and the change seems to be deliberate. Dude, we discussed this over a year ago, and we even tested it by including an deliberately ISO-only file in 4.18. Not a single user reported this as a problem with the 4.18 release, and I was watching closely for such a complaint. > It seems to me that the freedom of the gdb users is now restricted compared > to the previous versions because of the need of an ISO-C compiler instead > of any C compiler to compile it. > > And I do not understand why the same reasons that apply to binutils and gcc > do not hold for gdb. gdb, because it is better than the debugger you get > with your operating system, is needed to bootstrap the installation of > gas, gld, or gcc in the likely case that not everything works well > the first time. Indeed, I sent our results back to RMS, saying that there didn't seem to be any reason not to change the GNU coding standards for all GNU tools, including GCC and binutils. I don't know if he actually made the change though. So I think we've been sufficiently careful to ascertain whether the modernization was justified, and there is no good reason to try to revive K&R compat and the additional complexity that goes along with it. In fact, I've been a little disappointed that people haven't gone through random source files, and simplified their sources by stripping out all the now-unneeded K&R compat bits. Stan From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: nsd@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002121806.e1CI66F02876@delius.kettenis.local> References: <38A47E89.3F4674B3@mozilla.org> <882mue$s0f$1@cronkite.cygnus.com> X-SW-Source: 2000-q1/msg00245.html Content-length: 745 From: nsd@cygnus.com (Nick Duffek) Date: 12 Feb 2000 04:18:22 GMT In article < 38A47E89.3F4674B3@mozilla.org >, >There are also various problems with threads. A lot of times gdb >won't exit after the last thread exits because it keeps trying to >kill a process which doesn't exist any more. I've got a similar report from elsewhere; I'll be checking into it shortly. As I wrote in a reaction to Chris's message, this may very well be caused by a bug in LinuxThreads. I've seen several bug-reports about apps not exiting after the last thread finished. Apparently there is a race of some sort (surprise, surprise), and it may very well be that debugging with GDB just makes it more likely to trigger the race. Mark