On Tue, Feb 08, 2000 at 05:01:49PM -0500, Jim Kingdon wrote: > OK, I'm going to try to review the situation: > > I'm using http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=5130 as > the key bug/limitation that *I* want to fix but of course one of the > things which is making this confusing is that people keep switching > topics between various bugs (current and past). > This is a new patch. Please ignore the previous ones. H.J. ---- Tue Feb 8 18:19:22 2000 H.J. Lu Based on patches from Sam Lantinga (slouken@devolution.com): * solib.c (verify_solib): New function. Reload list of shared objects when they are added or deleted and dump symbols from unloaded shared objects. (solib_add): Call it. Index: solib.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 solib.c --- solib.c 1999/11/19 23:38:54 1.1.1.3 +++ solib.c 2000/02/09 02:18:55 @@ -194,6 +198,8 @@ static int solib_map_sections PARAMS ((P #ifdef SVR4_SHARED_LIBS +static void verify_solib PARAMS ((void)); + static CORE_ADDR elf_locate_base PARAMS ((void)); @@ -951,6 +957,69 @@ open_symbol_file_object (arg) } #endif /* SVR4_SHARED_LIBS */ +#ifdef SVR4_SHARED_LIBS +/* + +LOCAL FUNCTION + + verify_solib -- check solib list consistency and dump symbols + from unloaded shared objects + +SYNOPSIS + + void verify_solib (void) + +DESCRIPTION + + This module is called whenever we hit a dynamic linker + breakpoint and allows us to check the consistency of our shared + object list and unload objects which are no longer valid in the + in the inferior. Without this, dynamic unlinking of objects + could crash us. + +AUTHOR + Sam Lantinga + */ + +static void +verify_solib (void) +{ + struct objfile *current; + + if (debug_base) + { + read_memory (debug_base, (char *) &debug_copy, + sizeof (struct r_debug)); + /* If the shared object state is consistent, we can reload our + list */ + if ( debug_copy.r_state == RT_CONSISTENT ) + clear_solib(); + } + + for (current = symfile_objfile; current; current = current->next) + { + struct so_list *so; + char *bfd_filename; + for (so = so_list_head; so; so = so->next) + { + if (so->abfd) + { + bfd_filename = bfd_get_filename (so->abfd); + if (bfd_filename + && strcmp(bfd_filename, current->name) == 0) + break; + } + } + if ((current != symfile_objfile) && (so == NULL)) + { + /*printf("Freeing objfile: %s\n", current->name);*/ + free_objfile(current); + break; + } + } +} +#endif /* SVR4_SHARED_LIBS */ + /* LOCAL FUNCTION @@ -1165,6 +1234,8 @@ solib_add (arg_string, from_tty, target) int old; #ifdef SVR4_SHARED_LIBS + verify_solib (); + /* If we are attaching to a running process for which we have not opened a symbol file, we may be able to get its symbols now! */ From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: Dependence on config.status Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com> X-SW-Source: 2000-q1/msg00481.html Content-length: 816 > > Why does GDB need to be dependent on config.status, in addition to > > config.h? > > I don't know and yes I agree with you. I think it is just history. 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. I think that is still true (at least, I glanced through the Makefile.in and configure.in and that's what it looked like). Having said that, there is sometimes a tradeoff between having dependencies correct and having them useful. Making people type "make clean" in certain obscure situations may not be all that bad (although it tends to be pretty confusing as you usually don't realize what is going on until GDB is acting in strange and inexplicable ways). From tgl@sss.pgh.pa.us Sat Apr 01 00:00:00 2000 From: Tom Lane To: law@cygnus.com Cc: Daniel Berlin , 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: <27939.949983325@sss.pgh.pa.us> References: <4046.949979695@upchuck> X-SW-Source: 2000-q1/msg00157.html Content-length: 4251 Jeffrey A Law writes: >> 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... > Testcases please? If it's busted, it's news to me. This stuff was rock > solid when I stopped working on the PA port regularly a few years ago. OK, the case that's really biting my rear at the moment is that I can't get a backtrace from a corefile that has committed harakiri via abort(). I'm using gcc-2.95.2 and binutils-2.9.1: $ cat die.c #include int main(int argc, char* argv) { abort(); return 0; } $ gcc -v -g -O2 die.c Reading specs from /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/specs gcc version 2.95.2 19991024 (release) /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/cpp -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8 -DPWB -Dhpux -Dunix -D__hppa__ -D__hp9000s800__ -D__hp9000s800 -D__hp9k8__ -D__PWB__ -D__hpux__ -D__unix__ -D__hppa -D__hp9000s800 -D__hp9k8 -D__PWB -D__hpux -D__unix -Asystem(unix) -Asystem(hpux) -Acpu(hppa) -Amachine(hppa) -D__OPTIMIZE__ -g -D__hp9000s700 -D_PA_RISC1_1 -D_HPUX_SOURCE -D_HIUX_SOURCE -D__STDC_EXT__ die.c /var/tmp/ccOM2dGl.i GNU CPP version 2.95.2 19991024 (release) (hppa) #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/../../../../hppa2.0-hp-hpux10.20/include /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/../../../../include/g++-3 End of omitted list. /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/cc1 /var/tmp/ccOM2dGl.i -quiet -dumpbase die.c -g -O2 -version -o /var/tmp/ccWcvHuE.s GNU C version 2.95.2 19991024 (release) (hppa2.0-hp-hpux10.20) compiled by GNU C version 2.95.2 19991024 (release). /usr/local/hppa2.0-hp-hpux10.20/bin/as -o /var/tmp/ccC0G25b.o /var/tmp/ccWcvHuE.s /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/collect2 -L/lib/pa1.1 -L/usr/lib/pa1.1 -z -u main /usr/ccs/lib/crt0.o -L/usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib /var/tmp/ccC0G25b.o -lgcc -lc -lgcc $ ./a.out Abort(coredump) $ gdb a.out core GNU gdb 20000117 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "hppa2.0-hp-hpux10.20"... Core was generated by `a.out'. Program terminated with signal 6, Aborted. warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. Reading symbols from a.out...done. Reading symbols from /usr/lib/libc.1...done. Reading symbols from /usr/lib/libdld.1...done. #0 0xc0141120 in ?? () from /usr/lib/libc.1 (gdb) bt #0 0xc0141120 in ?? () from /usr/lib/libc.1 #1 0xc00aa744 in ?? () from /usr/lib/libc.1 #2 0xc008c258 in ?? () from /usr/lib/libc.1 #3 0xc0086c84 in ?? () from /usr/lib/libc.1 Cannot access memory at address 0x0 (gdb) If I compile without either -O2 or -O, I get (gdb) bt #0 0xc0141120 in ?? () from /usr/lib/libc.1 #1 0xc00aa744 in ?? () from /usr/lib/libc.1 #2 0xc008c258 in ?? () from /usr/lib/libc.1 #3 0xc0086c84 in ?? () from /usr/lib/libc.1 #4 0x2270 in main (argc=1, argv=0x7b03a5a0 "{\003 ") at die.c:5 #5 0xc00656bc in ?? () from /usr/lib/libc.1 (gdb) f 4 #4 0x2270 in main (argc=1, argv=0x7b03a5a0 "{\003 ") at die.c:5 5 abort(); (gdb) which is still not very helpful as far as the shlib goes, but at least I can find out where the heck the abort is. In any case, I thought gdb claimed to be able to debug optimized code. I'm running a fairly recent patchlevel of libc, HP's ld, dld, etc. If you need an exact patch set list, or any other info, let me know. regards, tom lane From scottb@netwinder.org Sat Apr 01 00:00:00 2000 From: Scott Bambrough To: karuottu@freenet.hut.fi Cc: "Lim, Sung-taek" , crossgcc mailinglist , gdb@sourceware.cygnus.com Subject: Re: Breakpoint problem when running on gdb-4.18 arm/thumb simulator target Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <387DE3A6.A2BCAB58@netwinder.org> References: <001401bf5db1$10157720$8f742e93@snu.ac.kr> <387DB7E5.E479256B@freenet.hut.fi> X-SW-Source: 2000-q1/msg00028.html Content-length: 1732 Kai Ruottu wrote: > > "Lim, Sung-taek" wrote: > > > Generally for the ARM-target it would be better to try the GDB snapshots. I don't > remember this phenomen from my gdb-4.18.x's, but perhaps I had updated some ARM-stuff > from the snapshots before building my first GDB for arm-elf... This is true. After the merge of the ARM Linux code, the number of testsuite failures has fallen according to the last reports I got from Stan. > Some targets had their 'opcodes' changed for the simulated 'breakpoint' instruction, > perhaps ARM was one of these. Anyway the synchronization between the binutils, GCC and > GDB hasn't been the best, and one must try more than one release before getting the > toolset to work. For arm-elf the '991130' and newer binutils seem to be broken. The > linked executables will not load into older or current GDBs (like Insight). ARM CPU's currently have no hardware support for breakpoints that I know of. GDB uses two approaches for breakpoints on ARM systems. On systems such as ARM Linux the OS has support for breakpoints in the kernel via a software interrupt. The instruction where the breakpoint occurs is replaced by a software interrupt call into the kernel. In embedded systems, with no such kernel support, an undefined instruction is used and GDB provides a handler for the undefined instruction trap. See the comments in tm-arm.h in the latest snapshot for more detail. > > the patch can be found at: > > http://poppy.snu.ac.kr/~totohero/arm-linux/gdb-4.18-dal-patch The current snapshot should build and work fine for most things from what I understand. Scott -- Scott Bambrough - Software Engineer REBEL.COM http://www.rebel.com NetWinder http://www.netwinder.org From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: New file gdb/CONTRIBUTE guidelins for the contributor Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <38A3780F.2FE7A510@cygnus.com> X-SW-Source: 2000-q1/msg00215.html Content-length: 1051 > In terms of content, this really is a direct lift of GCC's > how-to-contribute page. There is already such a lift at http://sourceware.cygnus.com/gdb/submit.html Although it does express things which need to be said (for the most part), I wanted to write something else which does more to encourage people (the submit.html page has way too many "don'ts" and not enough "dos"), so I wrote http://sourceware.cygnus.com/gdb/contribute.html (None of this is all that new, I've been checking in to GDB web pages since well before the Red Hat-Cygnus merger). The web pages are in CVS, people should be able to get them with some variation of cvs -d :ext:kingdon@sourceware.cygnus.com:/cvs/gdb co htdocs That is, how you get GDB but with the appropriate changes to the root/module names. So having said all that, do you still want submit.html or equivalent in the distribution? Having it both places seems like kind of a maintenance pain and seems to me that having the distribution point to the web site probably works. From toddpw@windriver.com Sat Apr 01 00:00:00 2000 From: Todd Whitesel To: gdb@sourceware.cygnus.com (GDB Developers) Subject: win32 native-process GDB target? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003152347.PAA13106@alabama.wrs.com> X-SW-Source: 2000-q1/msg00714.html Content-length: 574 I have a local request here for a GDB that can debug a win32 native process. More specifically, ELF objects dynamically loaded into a straight MSVC app. (It is better for me NDA-wise if I don't give any details beyond that.) Am I correct in assuming that the cygwin GDB requires its debuggee to also be cygwin? If so, then does anyone know the status of win32 native process target stuff? Unless it's recent, I'm pretty sure I haven't seen anything claiming to be such in the sources yet, so I'm afraid our guy may be out of luck. -- Todd Whitesel toddpw @ windriver.com From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: ac131313@cygnus.com Cc: gdb@sourceware.cygnus.com Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003051810.NAA09213@devserv.devel.redhat.com> References: <38BC81A0.17D25C8@cygnus.com> <38BE146B.46ED6E4D@cygnus.com> <200003021446.JAA31093@devserv.devel.redhat.com> <38C22262.FFA0191@cygnus.com> X-SW-Source: 2000-q1/msg00548.html Content-length: 36 > Try this: That looks fine to me. From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Mark Kettenis Cc: hjl@lucon.org, kingdon@redhat.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: <389F7168.67D263F1@cygnus.com> References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> <20000207093417.A10546@lucon.org> <200002072148.WAA08590@soliton.wins.uva.nl> X-SW-Source: 2000-q1/msg00147.html Content-length: 1301 Mark Kettenis wrote: > > Date: Mon, 7 Feb 2000 09:34:17 -0800 > From: "H . J . Lu" > > gdb 4.17.0.14 has one patch from Sam to deal with shared libraries. > People who want to debug shared libraries may not want to use gdb > in CVS. As you have mentioned above, it is not that unusual nowdays. > We have patches and they seem to work. We can make gdb 5.0 to work > with shared libraries. If we continue ignoring the working patches > without providing an alternative, we are sending the wrong signals > to those contributors. > > Yes we should try to act on bug-reports and look at the fixes we get > from people. However, we should keep an eye on the long-term > maintainability of GDB. Adding new hooks like Sam's patch does, is > not improving maitainability and contrary to the current direction > that GDB development is heading for: supporting multiple architectures > in one GDB binary. The patch is very useful though for establishing > what exactly is wrong, and how to fix this properly, which is what I > intend to do. It is possible that this doesn't happen before GDB 5.0 > however. This sounds like a situtation where the best thing to do is contribute the test case (assuming that such a test isn't already present). enjoy, Andrew From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: Jim Kingdon Cc: shebs@apple.com, gdb@sourceware.cygnus.com Subject: Re: Status Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38ACF5C3.E1A85C05@cygnus.com> References: <38A34041.B443DAFB@apple.com> <38A46C5C.F8301644@apple.com> <200002112037.PAA02309@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00335.html Content-length: 4048 Jim Kingdon wrote: > But I guess the GCC system makes sense to me. If something is enough > of an issue to be a "technical controversy" in the sense of something > people would escalate to the chief technical maintainer/team, you kind > of want to get people on board as much as possible. Because if you > proceed without _some_ level of consensus (not among the whole world, > but at least among a small group of people most involved), then it > creates various kinds of pain. I think the GCC system grew out of somewhat unusual (and very political) circumstances. In the case of GDB I think it is fair to say that the problem has been far simpler: Cygnus (a Red Hat company) (1) didn't keep up with the changing world and was slow (2) in moving the GDB repository to a public locale. That in turn both frustrated non Cygnus developers and created the persecption (real or otherwize) that Cygnus was hogging GDB. > I mean, there is almost always a way out (e.g. make it an option or > something, if there really a demand for both solutions). > > One thing I don't want to be single-string is the process of making > checkins which are believed to be relatively uncontroversial. Right > now there is a big problem when the person listed in MAINTAINERS for a > particular file gets busy or is on vacation or whatever. Or to put it > another way, being a maintainer should grant you the right to overrule > other people but it shouldn't grant you the right to stop things in > their tracks. Or something like that. In this regard, you'll notice that I've followed through the suggestion (from Eric Bachelo) that there be more than one person listed in under each problem domain. So far I've seen no comments. Returning to the actual committee (yes I've been put forward as a potential member). Quoting the GCC committee's page http://gcc.gnu.org/steering.html : ``Membership in the steering committee is a personal membership. Affiliations are listed for identification purposes only; steering committee members do not represent their employers or academic institutions.'' ``Generally speaking, committee members were chosen to represent the interests of communities (e.g. Fortran users, embedded systems developers, kernel hackers), not companies.'' I would argue that one key aspect the GCC stearing committee's success is that it has ensured that the committee members are considered individuals and are expected to ensure that any decisions made are both transparent and independant. This ain't no IOC :-) Following on from this, the GCC's committee's primary purpose was: ``to make major decisions in the best interests of the GCC project and to ensure that the project adheres to its fundamental principles found in the project's mission statement.'' (see http://gcc.gnu.org/gccmission.html ). and this points to the committees' second success. I being less concerned with direct technical issues it has allowed the GCC maintainers to persue GCC's development with rigor while still retaing coheasion within the project. As for what I think GDB should do? There is long term benefit in having a small, largely symbolic, group that ensure the independance of the maintainers. Such a group being selected using a criteria very similar to that of GCC (being truely independant and only having GDB's interests first). While such a group is being formed (is it a year now?) I think GDB should continue with the status-quo - a notional head maintainer but work delegated to problem domain maintainers. The main thing to ensure is that this group demonstrates technical independance when making day-to-day decisions. With regard to architectural and stategic problems I think they should continue to be debated and deveoped in a public forum. The criteria for debate being strictly technical. A committee might have a role but not as one that directly sets the development agenda. enjoy, Andrew (1) Sorry about this (2) Public CVS repositories are relatively recent phenomina when compared to the age of GDB :-) From eliz@delorie.com Sat Apr 01 00:00:00 2000 From: Eli Zaretskii To: hjl@valinux.com Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: A patch for ia32 hardware watchpoint. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003081132.GAA16847@indy.delorie.com> References: <20000307132613.B20282@valinux.com> X-SW-Source: 2000-q1/msg00597.html Content-length: 1455 > > @@ -5500,13 +5513,13 @@ watch_command_1 (arg, accessflag, from_t > > in hardware return zero. */ > > > > #if !defined(TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT) > > -#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(BYTE_SIZE) \ > > - ((BYTE_SIZE) <= (REGISTER_SIZE)) > > +#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL) \ > > + (TYPE_LENGTH (VALUE_TYPE (VAL)) <= (REGISTER_SIZE)) > > #endif > > > > #if !defined(TARGET_REGION_OK_FOR_HW_WATCHPOINT) > > -#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(ADDR,LEN) \ > > - TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(LEN) > > +#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(VAL) \ > > + TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL) > > #endif > > These are IMHO wrong: the number of debug registers required for a > particular region is a function of the address, not only size (e.g., a > single x86 debug register cannot watch a 32-bit region that isn't > aligned on 4-byte boundary). If Linux, for some reason, doesn't need > the address (although I cannot see how could this be right, at least > for native debugging), please define a platform-specific macro instead > of overwriting system-wide defaults. Sorry, I talked too soon. These changes supply all the required info, since they pass the entire struct value to the macro. So they are okay with me. I'm terribly sorry for jumping the gun for no reason. The rest of my comments about these patches are still valid, though. From gzp@gzp.org.hu Sat Apr 01 00:00:00 2000 From: "Gabor Z. Papp" To: gdb@sourceware.cygnus.com Subject: gdb cvs Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000302204824.B18856@gzp.org.hu> References: <200003021924.e22JO4U19747@mail.gzp.org.hu> X-SW-Source: 2000-q1/msg00513.html Content-length: 5091 | cvs server: Updating gdb | U gdb/CONTRIBUTE [...] | U gdb/vx-share/xdr_rdb.h | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/texinfo | cvs server: ignoring module src/texinfo | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/bfd | cvs server: ignoring module src/bfd | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/opcodes | cvs server: ignoring module src/opcodes | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/readline | cvs server: ignoring module src/readline | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/libiberty | cvs server: ignoring module src/libiberty | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/mmalloc | cvs server: ignoring module src/mmalloc | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/include | cvs server: ignoring module src/include | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/sim | cvs server: ignoring module src/sim | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/utils | cvs server: ignoring module src/utils | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/.cvsignore | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/COPYING | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/COPYING.LIB | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/ChangeLog | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/Makefile.in | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/README | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/config | cvs server: ignoring module src/config | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/config-ml.in | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/config.guess | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/config.if | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/config.sub | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/configure | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/configure.in | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/etc | cvs server: ignoring module src/etc | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/install-sh | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/ltconfig | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/ltmain.sh | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/makefile.vms | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/missing | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mkdep | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mkinstalldirs | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/move-if-change | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mpw-README | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mpw-build.in | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mpw-config.in | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mpw-configure | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/mpw-install | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/setup.com | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/symlink-tree | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src | cvs server: ignoring module src/ylwrap | cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/intl | cvs server: ignoring module src/intl Is this correct? From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: "Lim, Sung-taek" Cc: gdb mailinglist Subject: Re: How can I generate exceptions for arm-elf-gdb simulator target? Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38AA4995.6FF8DF90@cygnus.com> References: <003801bf6630$d9c9af00$8f742e93@snu.ac.kr> X-SW-Source: 2000-q1/msg00305.html Content-length: 193 "Lim, Sung-taek" wrote: > > I want to test my FIQ exception handlers in arm-elf-gdb simulator target. > How can I invoke such exceptions? Did anyone have an answer to this question? Andrew From shebs@shebs.cnchost.com Sat Apr 01 00:00:00 2000 From: Stan Shebs To: Kevin_Hendricks Cc: gdb@sourceware.cygnus.com, patl@cag.lcs.mit.edu Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38A0465C.DFF30C60@shebs.cnchost.com> References: <200002081520.KAA19603@hood.cnchost.com> X-SW-Source: 2000-q1/msg00168.html Content-length: 3139 Kevin_Hendricks wrote: > And while you are at it, why not fix gdb to actually work with ppc and actually > really and truly support a major platform (ppc) RIGHT_OUT_OF_THE_BOX god forbid! If the author of the patches doesn't want to put them in as-is, I for one am not going to override him... > I am so tired of fighting with non-working gdb on ppc that gdb has become next > to useless. I am now getting hangs with wierd thread errors when debugging > programs with Franz Sirl's gdb (and his is the *best* one I have found on ppc so > far). Now you know why we don't want to just hack in patches, eh? > 2. patches need to be in the right FSF format or we can't except them > (what bullshit) Depends on the project. GCC is usually much tougher about patches than GDB, so it surprises me you think it's easier to get a patch in there. > 3. we can't use your patch you have not signed a damn release > (again why do none of the other FSF project require this). This is simply not true. *Every* FSF project requires this. It may be that some maintainers are being sloppy (in which case they'll hear from RMS), and of course very small patches don't need an assignment. Note that the Linux kernel is not an FSF project, and they don't have any such rule. > Why is gdb so different? I'm most familiar with GCC, and one big difference between GCC and GDB is that GCC has more maintainers. I've been recruiting people to be GDB maintainers for years, and yet the list of people in gdb/MAINTAINERS is still very short, which sucks - it means that the few available people have to do all the work. We really do need more people to take up the responsibility for maintenance; Cygnus/Red Hat can't do it all. > Why can't it open up it process of getting patches in? If by "open up", you mean "lower the standards", then no, we don't want to do that. I know for instance that GCC has not lowered its standards, and indeed GDB has been criticized for having lower standards than some other projects. If you mean, "provide quicker feedback" on patches, yes, that is a known problem area. See my comment on the number of maintainers available. > Why is gdb development not geared to support Linux (any architecture) in any > reasonable manner? What do you mean by this? I don't see the development as being "geared" in any way - the development is driven by maintainers and contributors, all of whom we know by name. So if something is happening or not happening, it's because particular people are or are not working on it. If you mean "why is Kevin Buettner not working on PowerPC GDB enough" :-), you can ask him that directly. > So now we will have yet another new major gdb release without things working on > powerpc (expected!) or even x86 linux???. Last fall I said that one of the goals for 5.0 should be to support PowerPC Linux. I still think that should be a goal, but timing will be driven by the people who are actually doing the work, and by the amount of work, which, judging by your comments above, is more than I had thought. So it's going to take some committed effort to make it happen. Stan From fnasser@cygnus.com Sat Apr 01 00:00:00 2000 From: Fernando Nasser To: Grant Edwards 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: <38B58DAE.9CAA0A59@cygnus.com> References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com> X-SW-Source: 2000-q1/msg00404.html Content-length: 1476 Grant Edwards wrote: > > Another interesting bit of info. The new snapshot is apparently not > detecting the endianness of the target (both the sessions below were > with a Samsung SNDS evel board (big-endian): > I guess you got it. Can you set the endianess and do the load after that? Please let me know if it worked. In the meanwhile I will check for differences (my build is still going on :-) Thanks, Fernando > $ arm-elf-gdb > GNU gdb 4.18 > [...] > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf". > (gdb) target rdi /dev/ttyS1 > EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a) > Rebuilt on Apr 1 1998 at 00:43:57 > Serial Rate: 9600 > Connected to ARM RDI target. > (gdb) show endian > The target endianness is set automatically (currently big endian) > > > $ ~/gdb-000222/gdb/gdb > GNU gdb 000222 > [...] > This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf". > (gdb) target rdi /dev/ttyS1 > EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a) > Rebuilt on Apr 1 1998 at 00:43:57 > Serial Rate: 9600 > Connected to ARM RDI target. > (gdb) show endian > The target endianness is set automatically (currently little endian) > > -- > Grant -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Tel: 416-482-2661 ext. 311 Toronto, Ontario M4P 2C9 Fax: 416-482-6299 From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: GDB configure problem in the new repository... Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <38A41C50.F4E522DD@netwinder.org> <38A42322.90819896@netwinder.org> <38A7D838.185888FC@cygnus.com> X-SW-Source: 2000-q1/msg00265.html Content-length: 608 > The only problem with all this is that it is putting real pressure on > gdb/configure.in and gdb/Makefile.in (to be honest it's a bit of a > mess). Yeah, Someone (you know, Someone, that mythical volunteer) needs to come up with some kind of module system (like Apache or the linux kernel, probably, in that modules can either be linked in at run time or build time). There would be a variety of ways to set this up (some simpler than others) but it should be obvious that we need a general mechanism rather than the current ad hoc Insight and TUI bits in gdb/configure.in and gdb/Makefile.in. From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000 From: Jim Blandy To: Jim Kingdon 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: References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local> X-SW-Source: 2000-q1/msg00622.html Content-length: 537 > I do agree with HJ about one thing, though, which is that this issue > is rather important. I'm trying to put my money where my mouth is by > writing code but I'll have to admit that JimB's message left me a > little unsure about where to turn. You mean the vague "I don't understand the logic" comment? I concede that it's not especially constructive criticism. But it was the truth. :) I think I've got some idea of how to fix this, but you know how these things go --- don't let that stop you from thinking about it yourself. From tromey@cygnus.com Sat Apr 01 00:00:00 2000 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: Re: problems with gdb Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <87u2j8y822.fsf@cygnus.com> References: <38A47E89.3F4674B3@mozilla.org> <38AB2DC4.FA9A3C71@redhat.com> <38AB3457.6902@cup.hp.com> X-SW-Source: 2000-q1/msg00318.html Content-length: 729 >>>>> ">" == Srikanth writes: >> The difficulty here is that a name lookup could be >> based on either a demangled name or a mangled name. So unless we >> sort the table by both we will have to do linear search. Sorting >> the table by both involves heavy penalty at startup, as that >> entail three sorts with different keys (PC, demangled name and >> mangled name). We eliminated one of the keys : the demangled name >> and do a double sort. By eliminating this key don't you eliminate a valuable gdb feature? Anyway, you can avoid the sort penalty by using a hash table instead. You construct the hash table as you read the symbols. (That's what my patch does, as I recall.) Tom From alain.borlethote@free.fr Sat Apr 01 00:00:00 2000 From: "Alien" To: Subject: r_debug protocol Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <003f01bf71a5$d5e28d00$a355fea9@borlethote> X-SW-Source: 2000-q1/msg00134.html Content-length: 222 Hello! Where can I find some information about r_debug protocol (link.h, struct link_map) concerning shared library support? Thanks,                                         Alain