From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: eliz@is.elta.co.il Cc: gdb@sourceware.cygnus.com Subject: Re: Running the inferior from breakpoint commands Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003192249.e2JMn9X00629@delius.kettenis.local> References: <200003120759.CAA24402@indy.delorie.com> <5mem9ad1vw.fsf@jtc.redbacknetworks.com> <200003162229.e2GMTda00304@delius.kettenis.local> <200003182228.RAA07061@indy.delorie.com> X-SW-Source: 2000-q1/msg00740.html Date: Sat, 18 Mar 2000 17:28:26 -0500 (EST) From: Eli Zaretskii Perhaps you could apply the patch I sent and see if this test now works on these platforms. I'll do that eventually, but probably not in the next week. Mark >From fche@cygnus.com Sat Apr 01 00:00:00 2000 From: fche@cygnus.com (Frank Ch. Eigler) To: gdb@sourceware.cygnus.com Cc: Stephane.Bihan@arccores.com Subject: Re: how to integrate an ISS target in the gdb tree Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: X-SW-Source: 2000-q1/msg00747.html Content-length: 769 > [...] > I only need to integrate the simulator I guess. All the sources are in > sim/arc. Take a look at src/sim/README-HACKING. It has some bits and pieces on the subject. The main other things to watch for are: * sim/configure.in - to map target triples to sim/ subdirs Add a clause for your target. * sim//Makefile.in and configure.in - source tree build skeleton If you're using sim/common, copy these files from anther port such as d30v, mips, fr30. * populate sim/ and get things running. * Send a pack of patches. We can tidy up the build system here, if needed. I believe we will need an FSF copyright assignment, so you may want to get started on that paperwork in parallel. - FChE >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: Fernando Nasser Cc: gdb@sourceware.cygnus.com Subject: Re: 14 chars limit [Was: Re: Moving Linux-specific stuff out of Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003091238.HAA19879@indy.delorie.com> References: <38C6D2DC.44C3FC6@cygnus.com> <200003082121.e28LLRu05681@delius.kettenis.local> X-SW-Source: 2000-q1/msg00639.html Content-length: 212 > There are several files now with 14+ chars. I am just about to add > one (with 16). > > Is this still relevant? I would ask to make the files unique when truncated to 8.3 limits, if that's possible. Thanks! >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: gdb@sourceware.cygnus.com Subject: Restructuring i386_extract_return_value Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003092241.e29Mfow00303@delius.kettenis.local> X-SW-Source: 2000-q1/msg00660.html Content-length: 7725 Hi, Here are some other changes that I'm planning to make to the generic ix86 code. Since this affect several of the i386 targets I'd like to give the people involved with those targets the opportunity to object :-). The benefits are clear: support for `long long' return values on all targets that use this, and support for all floating-point types (including `long double') on all targets where GDB can access the FPU. Looking at the GCC sources and the Intel documentation, I believe that the attached patch is the right thing to do. Please refer to the detailed description below. I have verified that all targets that use i386_extract_return_value share the same register layout for the %eax and %edx registers. In addition to the attached patch some cleanup of the various tm-*.h files will be needed (remove definitions of {LOW,HIGH}_RETURN_REGNUM, get rid of the I386_*_TARGET defines where possible), I also think that the redefinition of EXTRACT_RETURN_VALUE in tm-i386v.h can go. Comments are welcome! Mark Return values ------------- There are three issues related to function return values: (1) floating-point return values, (2) 64-bit integer return values and (3) `struct' return values. 1. The majority of i386 targets in GCC return floating-point values by default on the FPU stack. In fact the only exception is NeXT. There is a switch `-mno-fp-ret-in-387' to force GCC to return floating-point values in the ordinary CPU registers. I don't think this can be determined from the debugging information. Is it worth adding a i386 target specific option to enable people to debug this code? Propably not. It seems reasonable to make i386-tdep.c:i386_extract_return_value() look for floating-point return values on the FPU stack if NUM_FREGS > 0, and issue a warning otherwise. Targets that return floating-point values in the CPU registers should provide their own function to extract return values, and override EXTRACT_RETURN_VALUE. Since NeXT isn't supported by GDB this isn't an issue right now. 2. As far as I can tell, all i386 targets return `long long' values in eax (low word) and edx (high word). This makes sense since this is the convention used by the machine instructions themselves. The relevant GCC code suggests that in addition to eax and edx, ecx might also be used for 12-byte values (then edx is the "middle" word, and ecx the high word). But since GCC doesn't have a 12-byte integer type (would that make sense?) this should never occur. However, the full 12-byte range is used for returning extended floating-point numbers (`long double'). Right now this is only implemented for AIX, Linux and DJGPP, but this should be made more general. 3. GCC can return `struct' and `union' values in registers when their size and alignment match some integer type. This is the default on several platforms where GCC is the only compiler (*BSD), and specified by the Win32 ABI (which is also used by Cygwin). Platforms that use the System V ABI (such as Linux) do not do this by default. Again there are switches (`-fpcc-struct-return' and `-freg-struct-return') that override the default. The behaviour is governed by USE_STRUCT_CONVENTION, and the default seems to be not to expect "small" structs to be returned in the registers unless GCC 1.x was used. This seems to be wrong for systems where -freg-struct-return is the default. 2000-03-09 Mark Kettenis * i386-tdep.c (LOW_RETURN_REGNUM, HIGH_RETURN_REGNUM): New defines. (i386_extract_return_value): Rewritten. Correctly support all floating-point types and large integer types on targets that use the standard i386 GDB register layout and return floating-point values in the FPU. Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.6 diff -u -p -r1.6 i386-tdep.c --- i386-tdep.c 2000/03/08 22:34:18 1.6 +++ i386-tdep.c 2000/03/09 22:03:54 @@ -698,56 +698,66 @@ get_longjmp_target (pc) #endif /* GET_LONGJMP_TARGET */ +/* These registers are used for returning integers (and on some + targets also for returning `struct' and `union' values when their + size and alignment match an integer type. */ +#define LOW_RETURN_REGNUM 0 /* %eax */ +#define HIGH_RETURN_REGNUM 2 /* %edx */ + +/* Extract from an array REGBUF containing the (raw) register state, a + function return value of TYPE, and copy that, in virtual format, + into VALBUF. */ + void -i386_extract_return_value (type, regbuf, valbuf) - struct type *type; - char regbuf[REGISTER_BYTES]; - char *valbuf; +i386_extract_return_value (struct type *type, char *regbuf, char *valbuf) { - /* On AIX, i386 GNU/Linux and DJGPP, floating point values are - returned in floating point registers. */ - /* FIXME: cagney/2000-02-29: This function needs to be rewritten - using multi-arch. Please don't keep adding to this #ifdef - spaghetti. */ -#if defined(I386_AIX_TARGET) || defined(I386_GNULINUX_TARGET) || defined(I386_DJGPP_TARGET) + int len = TYPE_LENGTH (type); + if (TYPE_CODE_FLT == TYPE_CODE (type)) { - double d; - /* 387 %st(0), gcc uses this */ - floatformat_to_double (&floatformat_i387_ext, -#if defined(FPDATA_REGNUM) - ®buf[REGISTER_BYTE (FPDATA_REGNUM)], -#else /* !FPDATA_REGNUM */ - ®buf[REGISTER_BYTE (FP0_REGNUM)], -#endif /* FPDATA_REGNUM */ + if (NUM_FREGS == 0) + { + warning ("Cannot find floating-point return value."); + memset (valbuf, 0, len); + } - &d); - store_floating (valbuf, TYPE_LENGTH (type), d); + /* Floating-point return values can be found in %st(0). */ + if (len == TARGET_LONG_DOUBLE_BIT / TARGET_CHAR_BIT + && TARGET_LONG_DOUBLE_FORMAT == &floatformat_i387_ext) + { + /* Copy straight over, but take care of the padding. */ + memcpy (valbuf, ®buf[REGISTER_BYTE (FP0_REGNUM)], + FPU_REG_RAW_SIZE); + memset (valbuf + FPU_REG_RAW_SIZE, 0, len - FPU_REG_RAW_SIZE); + } + else + { + /* Convert the extended floating-point number found in + %st(0) to the desired type. This is probably not exactly + how it would happen on the target itself, but it is the + best we can do. */ + DOUBLEST val; + floatformat_to_doublest (&floatformat_i387_ext, + ®buf[REGISTER_BYTE (FP0_REGNUM)], &val); + store_floating (valbuf, TYPE_LENGTH (type), val); + } } else -#endif /* I386_AIX_TARGET || I386_GNULINUX_TARGET || I386_DJGPP_TARGET */ { -#if defined(LOW_RETURN_REGNUM) - int len = TYPE_LENGTH (type); int low_size = REGISTER_RAW_SIZE (LOW_RETURN_REGNUM); int high_size = REGISTER_RAW_SIZE (HIGH_RETURN_REGNUM); if (len <= low_size) - memcpy (valbuf, regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM), len); + memcpy (valbuf, ®buf[REGISTER_BYTE (LOW_RETURN_REGNUM)], len); else if (len <= (low_size + high_size)) { memcpy (valbuf, - regbuf + REGISTER_BYTE (LOW_RETURN_REGNUM), - low_size); + ®buf[REGISTER_BYTE (LOW_RETURN_REGNUM)], low_size); memcpy (valbuf + low_size, - regbuf + REGISTER_BYTE (HIGH_RETURN_REGNUM), - len - low_size); + ®buf[REGISTER_BYTE (HIGH_RETURN_REGNUM)], len - low_size); } else - error ("GDB bug: i386-tdep.c (i386_extract_return_value): Don't know how to find a return value %d bytes long", len); -#else /* !LOW_RETURN_REGNUM */ - memcpy (valbuf, regbuf, TYPE_LENGTH (type)); -#endif /* LOW_RETURN_REGNUM */ + internal_error ("Cannot extract return value of %d bytes long.", len); } } >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Eli Zaretskii Cc: gdb@sourceware.cygnus.com Subject: Re: INSTALL set incorrectly in gdb/doc/Makefile Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38BCDC1C.2917C1D6@cygnus.com> References: <200002270838.DAA25037@indy.delorie.com> X-SW-Source: 2000-q1/msg00467.html Content-length: 937 Eli Zaretskii wrote: > > Does anyone else see problems with the value of INSTALL in > gdb/doc/Makefile? > > In my case, it gets set to "../". I did a bit of digging, and it > seems that the reason is that gdb/configure uses ac_given_INSTALL > right before it recurses into gdb/doc, but ac_given_INSTALL is not set > anywhere except config.status, which runs in a separate shell. > > I initially thought it was specific to DJGPP, but the above seems > quite general... Trying a configure on a bsd system I see: $ grep '^INSTALL' gdb/doc/Makefile INSTALL = /usr/bin/install -c INSTALL_PROGRAM = ${INSTALL} INSTALL_DATA = ${INSTALL} -m 644 > Am I missing something? I'm not sure. A guess is that your system doesn't have a real install program so configure is trying to set things up for src/install-sh (../../install-sh) Some how the ``install-sh'' (../install-sh) is getting lost. Look for ac_install_sh in configure. Andrew >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: help all? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <38A09F77.592FF0A5@cygnus.com> X-SW-Source: 2000-q1/msg00179.html Content-length: 420 > The list of all commands is really too big for being the default, but > a "help all" would not hurt anyone and make others happy. Not sure I have a strong reaction one way or the other (it sort of feels like a creeping feature which few people would notice/use but then again it seems harmless enough). One thing I did notice in the process of investigating is that "help help" is not nearly detailed enough. >From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000 From: Elena Zannoni To: gdb@sourceware.cygnus.com Subject: arguments to add-symbol-file Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <14554.41686.732151.870885@kwikemart.cygnus.com> X-SW-Source: 2000-q1/msg00781.html Content-length: 1022 Why when we use add-symbol-file 0x1000 0x2000 0x3000 gdb ends up with the following addrs structure, which includes explicit entries for .text, .data, and .bss section, plus the same 3 entries repeated in the 'other' array? Would it make sense to have only the 'other' part, or not include those three in 'other'? (top-gdb) p/x *addrs $35 = {text_addr = 0x1000, data_addr = 0x2000, bss_addr = 0x3000, other = {{ addr = 0x1000, name = 0x388510, sectindex = 0x0}, {addr = 0x2000, name = 0x388500, sectindex = 0x2}, {addr = 0x3000, name = 0x3884f0, sectindex = 0x3}, {addr = 0x0, name = 0x0, sectindex = 0x0} }} (top-gdb) p *addrs $36 = {text_addr = 4096, data_addr = 8192, bss_addr = 12288, other = {{ addr = 4096, name = 0x388510 ".text", sectindex = 0}, {addr = 8192, name = 0x388500 ".data", sectindex = 2}, {addr = 12288, name = 0x3884f0 ".bss", sectindex = 3}, {addr = 0, name = 0x0, sectindex = 0} }} Thanks Elena >From Peter.Schauer@regent.e-technik.tu-muenchen.de Sat Apr 01 00:00:00 2000 From: "Peter.Schauer" To: jimb@zwingli.cygnus.com (Jim Blandy) Cc: gdb@sourceware.cygnus.com Subject: Re: unloading shared objects Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003131759.SAA07581@reisser.regent.e-technik.tu-muenchen.de> References: X-SW-Source: 2000-q1/msg00688.html Content-length: 1587 > > There are at least two more subcases for this case (which should perhaps > > be mentioned in a FIXME), where _something_ needs to happen: > > > > - The DSO might have changed in the meantime, in which case we will > > have to reread it. Comparing timestamps between GDB's view > > of the DSO and the current DSO will detect this case. > > - The shared object is now loaded to another address, requiring > > relocation of the DSO in GDB's symbol tables etc. > > This might happen if another DSO increased in size since the > > last run, causing a relocation for the current DSO. > > Handling this requires comparison between the current objfile > > offsets and the computed offsets for the DSO in the inferior. > > The shared object list should be emptied each time the inferior is > started, exactly because the address at which a given shared object is > loaded may vary from run to run. Within a particular process, shared > objects never change address. We re-read each shared object's symbols > every time it is loaded. So I think these are handled trivially. Sorry for the confusion, I noticed this change in semantics a little a while after I sent the message. In older versions of GDB this was deemed unacceptable, as it was slowing down GDB to a crawl on every rerun if you had many shared libraries. With faster machines and auto-solib-add 0 we might get away with this approach (although using the old way and a smarter solib algorithm might have been beneficial for mozilla debugging :-). -- Peter Schauer pes@regent.e-technik.tu-muenchen.de >From dan@debian.org Sat Apr 01 00:00:00 2000 From: Daniel Jacobowitz To: 54734@bugs.debian.org Cc: gcc-bugs@gcc.gnu.org, gdb@sourceware.cygnus.com Subject: problems with line numbering Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000111004219.A8110@drow.res.cmu.edu> X-SW-Source: 2000-q1/msg00016.html Content-length: 4994 [Background included for the lists] Platform is ia32, Debian GNU/Linux; gcc is version 2.95.2; gdb is the snapshots from 19990928 and 20000110. When trying to debug apache, I ran into the obnoxious problem that breakpoints in functions were being put too far into the function. For example: (gdb) p invoke_cmd $1 = {char *(command_rec *, cmd_parms *, void *, char *)} 0x8054330 (gdb) break invoke_cmd Breakpoint 1 at 0x8054347: file http_config.c, line 810. A look at the beginning of invoke_cmd shows me: (gdb) x/20i invoke_cmd 0x8054330 : push %ebp 0x8054331 : mov %esp,%ebp 0x8054333 : sub $0xc,%esp 0x8054336 : push %edi 0x8054337 : push %esi 0x8054338 : push %ebx 0x8054339 : mov 0xc(%ebp),%edx 0x805433c : mov 0x4(%edx),%eax 0x805433f : mov 0x8(%ebp),%edx 0x8054342 : and 0xc(%edx),%eax 0x8054345 : jne 0x8054360 0x8054347 : push $0x0 Which corresponds to: static const char *invoke_cmd(const command_rec *cmd, cmd_parms *parms, void *mconfig, const char *args) { char *w, *w2, *w3; const char *errmsg; if ((parms->override & cmd->req_override) == 0) return ap_pstrcat(parms->pool, cmd->name, " not allowed here", NULL); In other words - that breakpoint is on the inside of the if statement. Thus it is not hit in any of the cases I was trying to debug. [End background] ---- OK, I see where the problem is. Again, the source chunk with a problem, line numbers added: 803 static const char *invoke_cmd(const command_rec *cmd, cmd_parms *parms, 804 void *mconfig, const char *args) 805 { 806 char *w, *w2, *w3; 807 const char *errmsg; 808 809 if ((parms->override & cmd->req_override) == 0) 810 return ap_pstrcat(parms->pool, cmd->name, " not allowed here", NULL); 811 812 parms->info = cmd->cmd_data; And the matching assembly: 00000ad0 : ad0: 55 push %ebp ad1: 89 e5 mov %esp,%ebp ad3: 83 ec 0c sub $0xc,%esp ad6: 57 push %edi ad7: 56 push %esi ad8: 53 push %ebx ad9: 8b 55 0c mov 0xc(%ebp),%edx adc: 8b 42 04 mov 0x4(%edx),%eax adf: 8b 55 08 mov 0x8(%ebp),%edx ae2: 23 42 0c and 0xc(%edx),%eax ae5: 75 19 jne b00 ae7: 6a 00 push $0x0 ae9: 68 63 02 00 00 push $0x263 aee: ff 32 pushl (%edx) af0: 8b 45 0c mov 0xc(%ebp),%eax af3: ff 70 10 pushl 0x10(%eax) af6: e9 28 06 00 00 jmp 1123 objdump -g shows something interesting: { /* 0xad0 */ register char *errmsg /* 0x0 */; register char *w3 /* 0x2 */; register char *w2 /* 0x6 */; register char *w /* 0x7 */; /* file /usr/src/debug/apache/apache-1.3.9/build-tree/apache_1.3.9/src/main/http_config.c line 805 addr 0xad0 */ /* file /usr/src/debug/apache/apache-1.3.9/build-tree/apache_1.3.9/src/main/http_config.c line 806 addr 0xad0 */ /* file /usr/src/debug/apache/apache-1.3.9/build-tree/apache_1.3.9/src/main/http_config.c line 809 addr 0xad0 */ /* file /usr/src/debug/apache/apache-1.3.9/build-tree/apache_1.3.9/src/main/http_config.c line 810 addr 0xae7 */ /* file /usr/src/debug/apache/apache-1.3.9/build-tree/apache_1.3.9/src/main/http_config.c line 812 addr 0xb00 */ Note that line 809, the if, is incorrectly listed as starting at 0xad0; it really starts at ad9. i386_skip_prologue() in gdb correctly figures this out, and then calls find_pc_sect_line on it, which says that the line goes from +ad0 to +ae7; because PROLOGUE_FIRSTLINE_OVERLAP is not defined, find_function_start_sal() skips ahead to the next line and breakpoints inside the if. I'd say this was both a gdb bug and a gcc bug. The debugging info for line 809 is definitely wrong, but gdb should be able to cope, IMO. I can see why PROLOGUE_FIRSTLINE_OVERLAP causes problems, but it definitely fixes this one. I'll send the .ii to gcc-bugs in a separate message, it's not relevant to the gdb list. Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | dan@debian.org | | dmj+@andrew.cmu.edu | \--------------------------------/ \--------------------------------/ >From agold@bga.com Sat Apr 01 00:00:00 2000 From: "Arthur H. Gold" To: gdb@sourceware.cygnus.com Subject: gdb does not `break' when using LD_PRELOAD Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <388F30C2.B6795E21@bga.com> X-SW-Source: 2000-q1/msg00059.html Content-length: 721 gdb list: Since upgrading to glibc-2.1.2, I've been having a problem with gdb-- specifically in regard to its use with LD_PRELOAD. The problem is that when running with a preloaded library (either from the shell or set within gdb) gdb fails to respect any breakpoints I set (though the breakpoints themselves seem to be set successfully). I understand there are problems with 4.18; I have, however, started to run 4.17-14 (HJ Lu's patched version)--but to no avail. Any input would be more than welcome TIA, --ag -- Artie Gold, Austin, TX (finger the cs.utexas.edu account for more info) mailto:agold@bga.com or mailto:agold@cs.utexas.edu -- A: Look for a lawyer who speaks Aramaic...about trademark infringement. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Michael Snyder Cc: dan@cgsoftware.com, 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: <38CDEDC5.4107034@cygnus.com> References: <200003031635.e23GZwi00372@delius.kettenis.local> <38C59074.2D7C@cygnus.com> <38C7EDFB.7457@cygnus.com> X-SW-Source: 2000-q1/msg00694.html Content-length: 1037 Michael Snyder wrote: > > > All i ever debug on BeOS is multi-threaded apps. > > Almost anything you do involves threads. > > Open a window, you've started at least 2 threads. > > File selection boxes fill in a seperate thread, etc. > > So i constantly have threads coming and going, and doing things. > > The hardest part of the whole port of gdb is telling gdb what > > happened, and making gdb do the right thing. > > On BeOS, we don't even have processes, just teams and threads. > > Everything on BeOS works, except typing run and have it start (you > > have to run and continue) :P. > > I looked at thread_db over the weekend, in hopes of being able to redo > > the port and get it into GDB (it's badly needing a rewrite anyway), > > but it still looks like it has too many problems. > > What problems are you referring to? > Right now the only one I'm aware of is that it doesn't > detect thread exit. Michael, Did you get any further with this? Did the problem exist in the old thread implementation for instance? Andrew >From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: hjl@lucon.org Cc: gdb@sourceware.cygnus.com Subject: Re: Problems with hardware watchpoint on ia32. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003091209.HAA19852@indy.delorie.com> References: <20000307132401.A20282@valinux.com> <200003081008.FAA16481@indy.delorie.com> <20000308084304.A3150@lucon.org> X-SW-Source: 2000-q1/msg00634.html Content-length: 2571 > I said it crushed because I spent 5 hours in gdb and were very close > to the problem, all of a sudden, I couldn't continue to debug in gdb > no matter what I did. To me, it has the same effect as crush. Understood. My problem was that I couldn't reproduce this particular problem: namely, if I use your test program, define 5 watchpoints, just like you did, run the debuggee, and after GDB complains, remove one of the watchpoints, I can then run the program without any problems. So I'm led to believe that this particular problem is specific to the Linux implementation of watchpoints. Perhaps the removal of the watchpoints doesn't work well in the case where insertion of watchpoints fails. I remember I had quite a few problems with getting it right in go32-nat.c. > > > Even worse, after deleted one hardware watchpoint, gdb still refused > > > to work. > > > > It works for me, but I have patches to do that, which I'm trying for 6 > > months to get accepted :-(. > > Should we at least review it? I posted them more than once in the past. Since a lot of water went under GDB's bridge since then, I now retrofitted the ones which are still relevant into the current snapshot, and I'm posting them in this thread in separate messages. > > Those patches also correct numerous other problems with watchpoints on > > x86, which you didn't mention. For example, try setting several > > watchpoints (of different types) on the same variable, and see the > > mess. Another problem which I corrected is that you cannot watch > > struct members, array elements, and bit fields with hardware-assisted > > watchpoints. > > I believe it is fixed in the currnt gdb. Problems with struct members and array elements are fixed, but bit fields are not. See my message about this, with a suggested patch. The problems with awatch and rwatch also aren't fixed; see my other message. > > > gdb won't set hardware watchpoints on long long nor double. > > > > You could look at go32-nat.c, it supports watching any region up to 16 > > bytes large. (I'm at a loss how come DJGPP needed to invent this: I'd > > expect any x86 platform to have this already, since watchpoints are > > such an indispensable tool in some circumstances.) > > > > Maybe we should have an i386hw-nat.c used by all ia32 platforms. I agree. If the implementation in go32-nat.c is close enough to what all platforms should do, I can volunteer to create i386hw-nat.c. (My primary lack of knowledge in this context is about ptrace-related limitations on using hardware debug registers.) >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: toddpw@windriver.com Cc: hjl@lucon.org, kettenis@wins.uva.nl, 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: <200003081441.JAA02876@devserv.devel.redhat.com> References: <200003080849.AAA18417@alabama.wrs.com> X-SW-Source: 2000-q1/msg00603.html Content-length: 460 > If each DSO was given its own obstack, it would be pretty easy. This is largely a solved problem (via objfiles). See my dlclose() patch: http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00454.html especially the call to free_objfile. Or for another example look at clear_solib which works one struct so_list at a time. There are a few loose ends in freeing, but it is the tangled logic in find_solib that is tripping us up more than the freeing. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: jtc@redback.com Cc: GDB Subject: Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C834AD.3379D1F2@cygnus.com> References: <200003080845.AAA18410@alabama.wrs.com> <5mitywc5ac.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00663.html Content-length: 1524 "J.T. Conklin" wrote: > > >>>>> "Todd" == Todd Whitesel writes: > jtc> I was planning to propose that the breakpoint pointer itself be passed > jtc> to the target_{insert,remove}_{break,watch}point() functions, so this > jtc> is as good of time as any. > > Todd> I say Just Do It. I am sitting on some local code here that tracks > Todd> breakpoints added to the target by a third party, and I ended up needing > Todd> the breakpoint shadow field to be available to those functions. > > I spent some time yesterday investigating what would be necessary to > change the target_{insert,remove}_breakpoint() API to pass a pointer > to struct breakpoint. > > What I have so far is change the API from: > int foo_insert_breakpoint (CORE_ADDR addr, char *shadow_contents); > to: > int foo_insert_breakpoint (struct breakpoint *bp, CORE_ADDR addr); J.T., One aspect of this gives me cold feet and sweety palms. You're giving the target code access to the entire bp struct. While I don't have any problems with handing the code a breakpoint handle, I have strong reservations towards any moves that give the target unfettered access to the entire ``struct breakpoint''. We'll be spending the next 10 years trying to get control back again :-) I'd prefer to see something that tightens rather than loosens access to ``struct breakpoint''. Perhaphs something along the lines of multi-arch where the target is notified of breakpoint create, insert, remove, delete operations. Andrew >From tgl@sss.pgh.pa.us Sat Apr 01 00:00:00 2000 From: Tom Lane To: Daniel Berlin Cc: gdb-testers@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <27617.949979286@sss.pgh.pa.us> References: X-SW-Source: 2000-q1/msg00152.html Content-length: 610 Daniel Berlin writes: >> Debugging shared libraries works most of time with gdb 4.17.0.14. >> If it doesn't work with 5.0, does that count for serious losses of >> functionality? > You mean for your particular architecture. I don't know what architecture H.J. is using, but I can tell you that shared lib debugging is completely nonfunctional on HPPA (HPUX 10.20). Can't even get a backtrace when execution is stopped in a shlib... kind of puts a crimp in the usefulness of gdb, at least for me. (If this has been fixed since the 20000117 snapshot then nevermind) regards, tom lane >From swarthou@ibmoto.com Sat Apr 01 00:00:00 2000 From: Edward Swarthout To: gdb@sourceware.cygnus.com Subject: State of native LinuxPPC patches Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200001182057.OAA26264@kuttanna.somerset.sps.mot.com> References: X-SW-Source: 2000-q1/msg00043.html Content-length: 1237 > Date: Thu, 21 Oct 1999 11:18:55 -0700 > From: Kevin Buettner > > I got my patches working with the head of the development tree several > weeks ago. (Actually, Gary Thomas deserves a lot of the credit.) > However there are a great many similarities between rs6000-tdep.c and > the ppclinux-tdep.c. I would really like to make the common parts > truly common as well as revamp it so that it uses the gdbarch > machinery, but this'll take more time than I have at the moment. So > it might be better for me to commit what I have so that linux/ppc is > supported in the Cygnus tree. Also, the longer I let my stuff sit, > the more likely it is that certain global changes will break what I > have working already. (Because these global changes won't have > happened to the linux/ppc stuff.) > Are these patches available in a sandbox somewhere? (Since there isn't native support yet, are they harmless enough to be released in cvs before being tested?) I have a LinuxPPC debug project I need to work on and I wanted to switch to the latest gdb snapshot before I did much gdb work. Thanks, Ed -------------------------------------- Ed.Swarthout@motorola.com Motorola Somerset Design Center Austin, TX