From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H . J . Lu" To: Eli Zaretskii Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com Subject: Re: gdb doesn't work very well with dynamic linked binaries Date: Mon, 04 Sep 2000 23:32:00 -0000 Message-id: <20000904233222.A13933@lucon.org> References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> X-SW-Source: 2000-09/msg00026.html On Tue, Sep 05, 2000 at 01:48:56AM -0400, Eli Zaretskii wrote: > > > > Date: Mon, 4 Sep 2000 16:44:58 -0700 > > From: "H . J . Lu" > > > > 1. Delete hardware watchpoints to free hardware debug registers. Set 4 > > hardware watchpoints. Then delete/disable one hardware watchpoint. Set > > another hardware watchpoint. Can gdb free a hardware debug register > > when I delete/disable the hardware watchpoint which uses it? > > 2. Watch for different values on a viariable with one hardware debug > > register. That is do > > > > (gdb) watch foobar == 1 > > (gdb) watch foobar == 2 > > (gdb) watch foobar == 3 > > (gdb) watch foobar == 4 > > (gdb) watch foobar == 5 > > > > only using one hardware debug register. > > > > I have reported them long before 5.0 was released. But at least #1 > > still doesn't work right in 5.0 under Linux/ia32. > > These are not GDB/ia32 issues per se: the above features are all > implemented in the DJGPP port of GDB and work in v5.0. Every > x86-based target should be able to lift the relevant parts of > go32-nat.c and use them almost verbatim. You get debug register > sharing through reference counts, and the ability to watch large > regions (up to 16 bytes) using multiple registers. (The required > infrastructure in high-level GDB application code, mostly in > breakpoint.c, is also working since v5.0.) > > What is missing is something that we discussed here some time ago: a > unified handling for debug registers common for ALL ia32 targets. If > you want to get this done before 5.1 is out, I'm for it. I said in > the past that I'm willing to volunteer to pull the code out of > go32-nat.c and generalize it as appropriate, as the first step towards > this goal. Provided that it's decided to do that for 5.1, of course > (otherwise, I have too many other important things to do ;-). > If you can generalize it for ia32, I will implement it for Linux/ia32. If it won't be fixed in 5.1, I will follow your hints and implement a Linux only solution when it happens to me again. It is just one of those things which makes me to roll my own stuff. Hardware watchpoints have been known to be broken on Linux/ia32 for a long time and nothing has been done to it. H.J. >From eliz@delorie.com Tue Sep 05 03:36:00 2000 From: Eli Zaretskii To: hjl@lucon.org Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com Subject: Re: gdb doesn't work very well with dynamic linked binaries Date: Tue, 05 Sep 2000 03:36:00 -0000 Message-id: <200009051035.GAA06054@indy.delorie.com> References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> X-SW-Source: 2000-09/msg00027.html Content-length: 1581 > Date: Mon, 4 Sep 2000 23:32:22 -0700 > From: "H . J . Lu" > > If you can generalize it for ia32, I will implement it for Linux/ia32. The code on go32-nat.c manipulates an array which represents the ia32 debug registers, including the status and control registers. It leaves it to resume() and its subroutines on the target end to actually insert the watchpoints when the inferior is resumed and remove them when the inferior stops and control is passed to GDB. If this model suits most or all ia32 targets, pulling the code from go32-nat.c into a separate module (probably, as part of i386-nat.c) would be very easy for me. If not, I'd ask the relevant maintainers to tell what provisions should I make for other platforms to fit in. > If it won't be fixed in 5.1, I will follow your hints and implement a > Linux only solution when it happens to me again. I can do this Very Soon (tm) provided that I hear a GO from The Powers That Be. Andrew? Stan? What say you? > Hardware watchpoints > have been known to be broken on Linux/ia32 for a long time and nothing > has been done to it. That's not 100% true: a few important patches related to watchpoints went into mainstream sources (mainly in breakpoint.c) in preparation for v5.0. This is the infrastructure I was talking about in my previous message; without those patches the watchpoint support in go32-nat.c could not work reliably. (IIRC, a major part of these patches were resubmitted by me and approved by Michael Snyder as a result of a discussion in which you participated.) >From gnalle@dirac.ruc.dk Tue Sep 05 03:56:00 2000 From: Niels L Ellegaard To: gdb@sourceware.cygnus.com Subject: gdb + egcs: break __raise_exception Date: Tue, 05 Sep 2000 03:56:00 -0000 Message-id: <7wr96zt9fu.fsf@dirac.ruc.dk> X-SW-Source: 2000-09/msg00028.html Content-length: 928 I am using gdb to debug a program compiled by egcs-2.91.66, and I would like to do the following: To make the debugger catch all exceptions before any stack unwinding takes place, set a breakpoint on __raise_exception (see section Breakpoints, watchpoints, and exceptions). I can easily break at other functions, but when I try to break at __raise_exception I get the following problem: (gdb) break __raise_exception Function "__raise_exception" not defined. I would be most greatful for any help. btw::~> gdb -version GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat .... This GDB was configured as "i486-pc-linux-gnu". -- Niels L Ellegaard http://dirac.ruc.dk/~gnalle/ SPECIAL OFFER! I proofread unsolicited commercial email sent to this address at a rate of US $500.00 per incident! Include billing address in your message and save US $500.00 per hour off ordinary address resolution and tracking charge! >From kettenis@wins.uva.nl Tue Sep 05 06:34:00 2000 From: Mark Kettenis To: eliz@is.elta.co.il Cc: hjl@lucon.org, gdb@sourceware.cygnus.com Subject: Re: gdb doesn't work very well with dynamic linked binaries Date: Tue, 05 Sep 2000 06:34:00 -0000 Message-id: <200009051333.e85DXsv12272@debye.wins.uva.nl> References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> <200009051035.GAA06054@indy.delorie.com> X-SW-Source: 2000-09/msg00029.html Content-length: 2232 Date: Tue, 5 Sep 2000 06:35:52 -0400 (EDT) From: Eli Zaretskii > Date: Mon, 4 Sep 2000 23:32:22 -0700 > From: "H . J . Lu" > > If you can generalize it for ia32, I will implement it for Linux/ia32. The code on go32-nat.c manipulates an array which represents the ia32 debug registers, including the status and control registers. It leaves it to resume() and its subroutines on the target end to actually insert the watchpoints when the inferior is resumed and remove them when the inferior stops and control is passed to GDB. If this model suits most or all ia32 targets, pulling the code from go32-nat.c into a separate module (probably, as part of i386-nat.c) would be very easy for me. If not, I'd ask the relevant maintainers to tell what provisions should I make for other platforms to fit in. I looked into the the hardware watchpoint support some time ago, and actually started coding, seperating the generic bits out of the go32 code. I was thinking of having some sort of register cache for the debugging registers but didn't immedeately see the right solution to do that. Perhaps they should simply be added to the register cache? I also couldn't directly see how the hardware watchpoint supports interacts with multiple threads, especially in presence of the nifty way the go32 code maps multiple waitchpoints on a single debugging register. In principle I see no reason why x86 hardware waitchpoints couldn't be implemented by i386-tdep.c though. > If it won't be fixed in 5.1, I will follow your hints and implement a > Linux only solution when it happens to me again. A generic x86 solution would be preferable, but a clean, well documented Linux-only solution is certainly welcome. I can do this Very Soon (tm) provided that I hear a GO from The Powers That Be. Andrew? Stan? What say you? > Hardware watchpoints > have been known to be broken on Linux/ia32 for a long time and nothing > has been done to it. Apparently nobody cares enough. It isn't at the top of my priority list so if nobody else contributes the necessary code, it probably won't happen in the near future. Mark >From kettenis@wins.uva.nl Tue Sep 05 07:41:00 2000 From: Mark Kettenis To: gnalle@dirac.ruc.dk Cc: gdb@sourceware.cygnus.com Subject: Re: gdb + egcs: break __raise_exception Date: Tue, 05 Sep 2000 07:41:00 -0000 Message-id: <200009051441.e85Efuh12357@debye.wins.uva.nl> References: <7wr96zt9fu.fsf@dirac.ruc.dk> X-SW-Source: 2000-09/msg00030.html Content-length: 794 From: Niels L Ellegaard Date: 05 Sep 2000 12:33:25 +0200 I am using gdb to debug a program compiled by egcs-2.91.66, and I would like to do the following: To make the debugger catch all exceptions before any stack unwinding takes place, set a breakpoint on __raise_exception (see section Breakpoints, watchpoints, and exceptions). I can easily break at other functions, but when I try to break at __raise_exception I get the following problem: (gdb) break __raise_exception Function "__raise_exception" not defined. I would be most greatful for any help. GDB cannot find the symbol "__raise_exception" in the executable. Did you verify (for example with `nm') that the executable does contain such a symbol? Mark >From hjl@lucon.org Tue Sep 05 08:44:00 2000 From: "H . J . Lu" To: Eli Zaretskii Cc: kettenis@wins.uva.nl, gdb@sourceware.cygnus.com Subject: Re: gdb doesn't work very well with dynamic linked binaries Date: Tue, 05 Sep 2000 08:44:00 -0000 Message-id: <20000905084429.B15547@lucon.org> References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> <200009051035.GAA06054@indy.delorie.com> X-SW-Source: 2000-09/msg00031.html Content-length: 1747 On Tue, Sep 05, 2000 at 06:35:52AM -0400, Eli Zaretskii wrote: > > Date: Mon, 4 Sep 2000 23:32:22 -0700 > > From: "H . J . Lu" > > > > If you can generalize it for ia32, I will implement it for Linux/ia32. > > The code on go32-nat.c manipulates an array which represents the ia32 > debug registers, including the status and control registers. It > leaves it to resume() and its subroutines on the target end to > actually insert the watchpoints when the inferior is resumed and > remove them when the inferior stops and control is passed to GDB. > > If this model suits most or all ia32 targets, pulling the code from > go32-nat.c into a separate module (probably, as part of i386-nat.c) > would be very easy for me. If not, I'd ask the relevant maintainers > to tell what provisions should I make for other platforms to fit in. > > > If it won't be fixed in 5.1, I will follow your hints and implement a > > Linux only solution when it happens to me again. > > I can do this Very Soon (tm) provided that I hear a GO from The Powers > That Be. Andrew? Stan? What say you? I will vote for fixing it in 5.1. I will do the Linux work since I brought it up. It has been broken for too long. There is no excuse not to fix it given that at least 2 people are willing to do it. > > > Hardware watchpoints > > have been known to be broken on Linux/ia32 for a long time and nothing > > has been done to it. > > That's not 100% true: a few important patches related to watchpoints > went into mainstream sources (mainly in breakpoint.c) in preparation Sorry for the misunderstanding. Thanks for your work on breakpoints. It is just that hardware watchpoints under Linux/ia32 are as broken as before :-). H.J. >From eliz@delorie.com Tue Sep 05 08:47:00 2000 From: Eli Zaretskii To: kettenis@wins.uva.nl Cc: hjl@lucon.org, gdb@sourceware.cygnus.com Subject: Re: gdb doesn't work very well with dynamic linked binaries Date: Tue, 05 Sep 2000 08:47:00 -0000 Message-id: <200009051546.LAA06234@indy.delorie.com> References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> <200009051035.GAA06054@indy.delorie.com> <200009051333.e85DXsv12272@debye.wins.uva.nl> X-SW-Source: 2000-09/msg00032.html Content-length: 2140 > Date: Tue, 5 Sep 2000 15:33:54 +0200 (MET DST) > From: Mark Kettenis > > I was thinking of having some sort of register cache for the > debugging registers but didn't immedeately see the right solution to > do that. Perhaps they should simply be added to the register cache? I think all we need is to store the debug registers somewhere. They need to be accessed by (1) the x86-dependent code which is called by GDB's application level to insert and remove watchpoints; (2) the target-specific code which actually calls ptrace or the equivalent syscall to pass the values into the inferior's registers before resuming it, and set bits after the inferior stops to indicate which watchpoint(s) triggered; and (3) by stopped_by_watchpoint's target end. It's possible that the register cache is as good place as any to store DRi, even though they slightly differ from the rest of the registers. > I also couldn't directly see how the hardware watchpoint supports > interacts with multiple threads Sorry, I'm not sure I see the problem. Could you please elaborate? (I'm afraid I don't know much about Linux threads.) > especially in presence of the nifty way the go32 code maps multiple > waitchpoints on a single debugging register. I don't think this should matter. The reference counts are just a means to know which register is used and which isn't. As far as the higher-level GDB code is concerned, what's important is (a) which address, if any, triggered a watchpoint; and (b) which thread caused the watchpoint to trigger. However, if I'm missing the point, and there's some additional infrastructure that is required to make this work with multiple threads, please tell what is, or might be, missing. > Apparently nobody cares enough. It isn't at the top of my priority > list so if nobody else contributes the necessary code, it probably > won't happen in the near future. If v5.1 freeze date is far away, and if the current code in go32-nat.c is good enough to be used by other x86 platforms, I might take the silence as a sign of agreement, given the fact that making it happen is easy... ;-) >From hjl@lucon.org Tue Sep 05 08:49:00 2000 From: "H . J . Lu" To: Mark Kettenis Cc: eliz@is.elta.co.il, gdb@sourceware.cygnus.com Subject: Re: gdb doesn't work very well with dynamic linked binaries Date: Tue, 05 Sep 2000 08:49:00 -0000 Message-id: <20000905084923.C15547@lucon.org> References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org> <200009041751.e84HprD11517@debye.wins.uva.nl> <20000904164458.A12270@lucon.org> <200009050548.BAA05890@indy.delorie.com> <20000904233222.A13933@lucon.org> <200009051035.GAA06054@indy.delorie.com> <200009051333.e85DXsv12272@debye.wins.uva.nl> X-SW-Source: 2000-09/msg00033.html Content-length: 1070 On Tue, Sep 05, 2000 at 03:33:54PM +0200, Mark Kettenis wrote: > > > If it won't be fixed in 5.1, I will follow your hints and implement a > > Linux only solution when it happens to me again. > > A generic x86 solution would be preferable, but a clean, well > documented Linux-only solution is certainly welcome. Given do it clean, do it fast and make it to work, you can only pick 2 if I am the only one to do it. Since I don't have much time to do it, I have to pick do it fast. > > I can do this Very Soon (tm) provided that I hear a GO from The Powers > That Be. Andrew? Stan? What say you? > > > Hardware watchpoints > > have been known to be broken on Linux/ia32 for a long time and nothing > > has been done to it. > > Apparently nobody cares enough. It isn't at the top of my priority > list so if nobody else contributes the necessary code, it probably > won't happen in the near future. It has to be fixed in 5.1, one way or the other. The worst case is I will make my kludge available to the Linux community. H.J. >From msokolov@ivan.Harhan.ORG Tue Sep 05 10:44:00 2000 From: msokolov@ivan.Harhan.ORG (Michael Sokolov) To: binutils@sources.redhat.com, crossgcc@sources.redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: An article about the Cygnus tree Date: Tue, 05 Sep 2000 10:44:00 -0000 Message-id: <0009051743.AA01913@ivan.Harhan.ORG> X-SW-Source: 2000-09/msg00034.html Content-length: 2896 Joe Buck wrote: > Still wrong. The FSF never "closed their gcc project". This *is* the gcc > project. Same people for the most part, same code base. Not quite. Yes, politically it's the same project, has many of the same people, and the core code is a version of the same thing. But this is not what my article is about. My article is about the Cygnus tree, the top-level architecture, and the fact that all these projects are now dependent on the tree architecture and belong in the single unified repo. The old gcc which had all the actual gcc code at the top directory level and no libiberty *is* dead. The other, once forked, GCC that has the Cygnus configure script at the top directory level is the only one remaining. That was my whole point. > > BTW, what did EGCS stand for? > > eggs. I've checked in this: ------- cygnus-tree-intro ------- *** /tmp/d01094 Tue Sep 5 11:28:02 2000 --- cygnus-tree-intro Tue Sep 5 11:10:11 2000 *************** *** 42,52 **** its development, so Cygnus didn't take over its development by itself. First they synchronised their work on it (in their internal Cygnus tree) with the FSF maintainers. Then in August 1997 they created an open development project for ! it which they named EGCS (Extended GNU Compiler System). It was a public ! project and for a period of time, for better or worse, was in competition with ! FSF's gcc project. In spring 1999 FSF closed their gcc project and EGCS was ! renamed into GCC. At the same time GCC was changed to mean GNU Compiler ! Collection instead of GNU C Compiler. All these programs have been integrated into the Cygnus tree so completely that they no longer exist separately from it. Moreover, some of these programs are --- 42,52 ---- its development, so Cygnus didn't take over its development by itself. First they synchronised their work on it (in their internal Cygnus tree) with the FSF maintainers. Then in August 1997 they created an open development project for ! it which they named EGCS (eggs, just like the ones Americans eat for breakfast ! :-). It was a public project and for a period of time, for better or worse, was ! in competition with FSF's gcc project. In April 1999 FSF closed their gcc ! project and EGCS was renamed into GCC. At the same time GCC was changed to mean ! GNU Compiler Collection instead of GNU C Compiler. All these programs have been integrated into the Cygnus tree so completely that they no longer exist separately from it. Moreover, some of these programs are -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) >From msokolov@ivan.Harhan.ORG Tue Sep 05 10:54:00 2000 From: msokolov@ivan.Harhan.ORG (Michael Sokolov) To: binutils@sources.redhat.com, crossgcc@sources.redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: An article about the Cygnus tree Date: Tue, 05 Sep 2000 10:54:00 -0000 Message-id: <0009051753.AA02054@ivan.Harhan.ORG> X-SW-Source: 2000-09/msg00035.html Content-length: 1110 "Russ.Shaw" wrote: > I think there should be a newsgroup for the gnu tools etc, for applications > involving embedded systems. comp.arch.embedded is more hardware oriented. > What about a comp.gnu.embedded for all questions on installation, development, > use, and abuse of gnu/cygnus/open-source tools for embedded systems? How is the crossgcc mailing list not enough for you for this purpose? That's exactly what it's for. But what my article calls for is quite different. Here I'm concerned mostly with the *core developers*. I'm calling for the /cvs/src and /cvs/gcc repos on Sourceware to be merged and for creating a home for the Cygnus tree concerned with its core development and maintenance, rather than "abuse" you are talking about. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) >From nickc@redhat.com Tue Sep 05 11:58:00 2000 From: Nick Clifton To: scottb@netwinder.org Cc: gdb@sources.redhat.com, ac131313@cygnus.com Subject: Re: src/ltcf-c.sh Date: Tue, 05 Sep 2000 11:58:00 -0000 Message-id: <200009051858.LAA02214@elmo.cygnus.com> X-SW-Source: 2000-09/msg00036.html Content-length: 903 Hi Scott, : The autobuild at netwinder.org fails with the following error: : : /home/build-rpm/BUILD/gdb/opcodes/../ltconfig: : /home/build-rpm/BUILD/gdb/opcodes/../ltcf-c.sh: No such file or directory : configure: error: libtool configure failed : Configure in /home/build-rpm/BUILD/obj-gdb-20000904/opcodes failed, exiting. : Bad exit status from /var/tmp/rpm-tmp.88907 (%build) : : The problem is a cvs checkout of gdb is not updating this file. It isn't : there so the build fails. I had a look at the modules file, and it is : included in the alias src-support, which is included in gdb-support which is : used by the gdb module. If I update my binutils tree, and my insight trees : the file is not checked out, though I expect it to be. If I check it out : manually by cvs co ltcf-c.sh, it works. : : Any ideas? Strange. It seems to work for us. Maybe this is a CVS bug ? Cheers Nick >From jbuck@racerx.synopsys.com Tue Sep 05 12:01:00 2000 From: Joe Buck To: msokolov@ivan.harhan.org (Michael Sokolov) Cc: binutils@sources.redhat.com, crossgcc@sources.redhat.com, gcc@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: An article about the Cygnus tree Date: Tue, 05 Sep 2000 12:01:00 -0000 Message-id: <200009051859.LAA04233@racerx.synopsys.com> References: <0009051743.AA01913@ivan.Harhan.ORG> X-SW-Source: 2000-09/msg00037.html Content-length: 2141 > > Joe Buck wrote: > > > Still wrong. The FSF never "closed their gcc project". This *is* the gcc > > project. Same people for the most part, same code base. > > Not quite. Yes, politically it's the same project, has many of the same people, > and the core code is a version of the same thing. But this is not what my > article is about. My article is about the Cygnus tree, the top-level > architecture, and the fact that all these projects are now dependent on the > tree architecture and belong in the single unified repo. I am starting to see the problem. You are confusing several things together and mashing them into one concept that you are calling "the Cygnus tree". Concept #1 is the software architecture that allows for a top-level makefile with tools placed underneath that top level that can be built all in one step. Yes, this was invented by folks at Cygnus. But what you're failing to see is that this system was designed so that a GNU source directory can be made a subdirectory and then built *without changing it*. Since you don't appreciate that, you falsely believe that a huge change had to be made to gcc to get it to build within this structure. Not at all: it just drops in. The Cygnus folks had to do it that way to work and play successfully with GNU maintainers that did not use the structure. Similarly, we noticed in the early days of egcs that the makeinfo sources were a lot smaller than the .info files, so we decided to include the source in the distribution (maybe not the greatest decision). It was not necessary to change texinfo/makeinfo to do this. Because you make this mistake, you think that gcc underwent a larger technical change than it did. In fact, you appear to believe that this was a revolution or something. Surprise: it is no big deal. Concept #2 is the CVS archive that Cygnus (now Red Hat) makes releases from for their own customers. This tree is *not* the same as the "net" version of gcc (or egcs before it). In many cases, work that Cygnus did went to customers first and only later was merged into the egcs or GCC distribution.