From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Taylor To: Daniel Berlin Cc: gdb@sourceware.cygnus.com Subject: Re: Another Issue for 5.0 Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002181809.NAA06156@texas.cygnus.com> X-SW-Source: 2000-q1/msg00337.html Date: Thu, 17 Feb 2000 08:26:39 -0800 (PST) From: Daniel Berlin IMHO, the overload resolution for DWARF2/STABS/all non-hp platforms should really be fixed for 5.0. I have patches to do this (in fact, i'm about to send another jumbo patch to gdb-patches with it all combined so i don't have to keep emailing it to people :P), with no regressions, well, actually, that's not true. Some overload resolution things that were xfail before in the testsuite now pass. Sorry about that. I'll try to make sure i keep the broken things broken in the future. :P But, anyway, i get about 5-10 emails a week asking for those patches. Even on HP using aCC, where overload resolution works, you get benefits because i added support for references in overloads, and fixed a problem where the compares against function names were whitespace sensitive where they shouldn't have been (so operator [] would be considered the same function as operator[] when we were hunting down overloads). Maybe i'm biased, but anyone working on C++ programs would love it. I'm starting to work on other C++ language support related things, if anyone has any specific requests, let me know. --Dan Is there a copyright assignment on file? I'd love to look over the patch. >From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000 From: Jim Blandy To: Todd Whitesel Cc: gdb@sourceware.cygnus.com (GDB Developers) Subject: Re: symfile.c:symfile_bfd_open() Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <200003241351.FAA06850@alabama.wrs.com> X-SW-Source: 2000-q1/msg00804.html Content-length: 1075 > While merging up to 4.18 (as a stepping stone to devo), I noticed > something that we're doing locally here which seems generally useful > for cross developing folks. > > symfile.c:symfile_bfd_open() opens objects/executables using BFD. > > It tells openp() to search the $PATH, which is obviously handy for > native, but seems to make no sense whatsoever for cross development. Yep. > Our local patch is to add a second argument to symfile_bfd_open, > "use_source_path", which ends up being set to 1 nearly all of the > time, since with our targets we are always cross developing. In > that case, we have openp() search source_path instead of getenv("PATH"). How do you decide what to pass for the use_source_path argument? Is it a user-settable option? > Does the multi-arch stuff provide a clean test for native vs. cross? > That'd be a better decision-maker than the "use_source_path" argument. I don't think you can tell at all. What if I'm debugging an i386 embedded system on Linux? Then, whether I'm native or remote is a matter of which target I select. >From hjl@lucon.org Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: Chris Blizzard Cc: Christopher Blizzard , tromey@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000218101700.A19913@lucon.org> References: <38A47E89.3F4674B3@mozilla.org> <38AB2DC4.FA9A3C71@redhat.com> <87zot0y99f.fsf@cygnus.com> <38AC0B97.19AE4BAE@mozilla.org> <38AD8469.27616453@redhat.com> X-SW-Source: 2000-q1/msg00338.html Content-length: 415 On Fri, Feb 18, 2000 at 12:42:01PM -0500, Chris Blizzard wrote: > Christopher Blizzard wrote: > > > > Program received signal SIGTRAP, Trace/breakpoint trap. > > 0x404cbd41 in ?? () from /lib/libc.so.6 > > (gdb) shar libc.so.6 > > Reading symbols from /lib/libc.so.6...done. > > There are many linuxthreads problems since lin-thread.c was introduced. Unfortunately, I don't have the time to track it down. H.J. >From rearnsha@arm.com Sat Apr 01 00:00:00 2000 From: Richard Earnshaw To: "Xavier Bestel" Cc: rearnsha@arm.com Subject: Re: single-step Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002281725.RAA24931@cam-mail2.cambridge.arm.com> References: <045d01bf820f$922ce7c0$30fd62c2@aplio.fr> X-SW-Source: 2000-q1/msg00440.html Content-length: 684 > ok, so if I understood the system, when SOFTWARE_SINGLE_STEP_P=1, > SOFTWARE_SINGLE_STEP is the function which emulates the singlestepping using > breakpoints. > but if I don't define SOFTWARE_SINGLE_STEP_P, or if I define it to 1, then > do I have to provide a specialized SOFTWARE_SINGLE_STEP_P() ? There is no > such thing in tm-arm.h. Arggh! Sorry, I've mislead you. I've got some local patches in my tree for doing that and I'd forgotten that I hadn't submitted them yet. I'm sure this code used to be there, but for some reason it has been deleted. It appears that at this time, you can't single step if there is no hardware or OS support for the feature. Richard.