From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: "H . J . Lu" Cc: Mark Kettenis , jtc@redback.com, shebs@apple.com, gdb@sourceware.cygnus.com Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C82D34.31E36610@cygnus.com> References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> X-SW-Source: 2000-q1/msg00661.html "H . J . Lu" wrote: > > This patch is definitly much better than the original. > > > > Unfortunatly, I don't think that selecting a pre-installed regexp should > > be the default. My rationale (As Mark? noted) is that ensuring that a > > GDB release provides consistent behavour between systems (1) is more > > Please remember, we, Linux, want to provide a consistent behavour > cross the whole system. I think, Cygnus and FSF, haven't got rid of > the idea that you are providing some replacements for some existing > programs. When you build a Linux system from the source, do you like > N copies for the same thing everywhere? If I were you, I would want > everyone to use the While I can understand viewpoint you're attributing to both that company formally known as Cygnus and the FSF, it wasn't actually my overriding concern (As an asside, the (1) ment to have a footnote pointing out I had GNU/Linux systems in mind when I wrote this). I would like to see GDB-5 provide consistent behavour across all the random GNU/Linux distributions that are out there. I think this is consistent with other applications that rely on regexp - VI being a very very good example. I also want to be able to say, with some certainty, that a users regexp problem is attributable to GDB and _not_ random regexp of the day. A GNU/Linux distributor is free to build a GDB that regexp from an installed glibc. Actually such a distributor is free to do what ever they like :-) enjoy, Andrew >From Guenther.Grau@marconicomms.com Sat Apr 01 00:00:00 2000 From: Guenther Grau To: "H . J . Lu" Cc: gdb@sourceware.cygnus.com Subject: Re: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C7EE20.FFD45517@marconicomms.com> References: <38C585BB.3F7B1AC7@apple.com> <20000307155806.A30106@valinux.com> <5mg0u2l3g0.fsf@jtc.redbacknetworks.com> <20000307162127.D485@lucon.org> <200003080044.e280iGB00429@delius.kettenis.local> <5m4saivyew.fsf@jtc.redbacknetworks.com> <38C7B8BD.26C0E220@cygnus.com> <38C7C369.97CF2A7F@marconicomms.com> <20000309100518.A7546@lucon.org> X-SW-Source: 2000-q1/msg00655.html Content-length: 2675 "H . J . Lu" wrote: > > On Thu, Mar 09, 2000 at 04:29:45PM +0100, Guenther Grau wrote: > > Andrew Cagney wrote: > > > > > [...] > > > > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00562.html > > > > http://sourceware.cygnus.com/ml/gdb-patches/2000-q1/msg00566.html > > > > > > This patch is definitly much better than the original. > > > > > > Unfortunatly, I don't think that selecting a pre-installed regexp should > > > be the default. My rationale (As Mark? noted) is that ensuring that a > > > GDB release provides consistent behavour between systems (1) is more > > > important than having it select the latest/greatest random regexp. > > > > I support this (not that it matters :-). If H.J. Lu wants it on > > Linux, he can ./configure --with-libc-regex or --with-native-regex, > > --with-libc-regex and --with-native-regex are misleading since > the regex in gdb coms from the Linux C library. It might be a derived version, but it is not the same. So what's the problem with these names? And if you don't like them, find another name that suits you :-) How about --with-linux-libc-regex-and-not-the-linux-libc-derived-version-within-gdb or --with-working-native-regex ;-) ? What, if the gdb regex-implementation were not derived from the linux libc-regex implementation? Would you still care about the name of the option? Is this a problem of gdb not giving credit to the linux regex implementation? There is a lot of stuff in linux which doesn't give proper credit to the original work it was derived from. > > but the default should be the regex within gdb. > > Are you speaking as a Linux/Hurd user? As far as I know, my patch will No. > only affect Linux and Hurd? If you are a Linux/Hurd user, do you > have a "known to work" regex in your C library? If not, should you > be worried? Well, that depends. People running an old Linux with a broken regex should probably be worried, but if they are still using it, they haven't encountered the bugs yet, so why worry? If they encounter the bug later somewhen with a different application, they probably blame the other application, but not gdb. If they put the next gdb release on their system and it doesn't run properly due to regex problems, they blame gdb, not the broken regex implementation in libc. This is what we should avoid. IMHO, the best solution would be to create a set of tests, which check if the native regex implementation works properly and decide which implementation to use based on this result (and maybe even tell the user to upgrade their bogus version of libc). This is what ./configure is all about. The only problem is that it is a lot more work. Guenther >From hjl@lucon.org Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: Jim Kingdon Cc: toddpw@windriver.com, kettenis@wins.uva.nl, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Another revised patch for dlclose Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000308103740.A3530@lucon.org> References: <200003080849.AAA18417@alabama.wrs.com> <200003081441.JAA02876@devserv.devel.redhat.com> X-SW-Source: 2000-q1/msg00611.html Content-length: 4624 On Wed, Mar 08, 2000 at 09:41:00AM -0500, Jim Kingdon wrote: > > 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. Here is a new patch. It seems to work with the testcase. Any comments? H.J. ---- 2000-03-08 H.J. Lu Inspired by patches from Sam Lantinga (slouken@devolution.com): * solib.c (solib_verify): New function. Unload the shared object when it is deleted and dump symbols from the unloaded shared object. * solib.h (SOLIB_VERIFY): New. Defined as solib_verify. * infrun.c (handle_inferior_event): Also call SOLIB_VERIFY () if it is defined when we hit the internal debug breakpoint for shared libraries in the dynamic linker. Index: solib.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v retrieving revision 1.1.1.4 retrieving revision 1.7 diff -u -p -r1.1.1.4 -r1.7 --- solib.c 2000/03/07 18:42:17 1.1.1.4 +++ solib.c 2000/03/08 18:36:11 1.7 @@ -950,6 +950,84 @@ open_symbol_file_object (arg) return 1; } #endif /* SVR4_SHARED_LIBS */ + +/* + +GLOBAL FUNCTION + + solib_verify -- check solib list consistency and dump symbols + from unloaded shared objects + +SYNOPSIS + + void solib_verify (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. This function should only be called when we + hit the internal debug breakpoint for shared libraries in the + dynamic linker. + + */ + +void +solib_verify (void) +{ +#ifdef SVR4_SHARED_LIBS + if (debug_base) + { + static int solib_unloading = 0; + + read_memory (debug_base, (char *) &debug_copy, + sizeof (struct r_debug)); + if (debug_copy.r_state == RT_DELETE) + solib_unloading = 1; + else if (solib_unloading && debug_copy.r_state == RT_CONSISTENT) + { + struct so_list *so = NULL, *next, *so_next, *saved; + + /* Get the current list of loaded shared libraries. */ + saved = so_list_head; + so_list_head = NULL; + while ((so = find_solib (so)) != NULL); + so = so_list_head; + so_list_head = saved; + + /* We compare the current list against what we have. */ + for (next = so_list_head; next; next = next->next) + { + for (so_next = so; so_next; so_next = so_next->next) + if (strcmp (so_next->so_name, next->so_name) == 0) + break; + + if (!so_next) + { + /* We didn't find it in the current list. Unload it. + Since the dynamic linker can only unload one + shared library at a time, we stop here. Also + free_objfile () will call clear_solib (). It will + clear everything for us. */ + free_objfile (next->objfile); + break; + } + } + + /* Free the current list of loaded shared libraries. */ + for (so_next = so; so_next; so_next = next) + { + next = so_next->next; + free (so_next); + } + + solib_unloading = 0; + } + } +#endif /* SVR4_SHARED_LIBS */ +} /* Index: solib.h =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/solib.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -p -r1.1.1.1 -r1.2 --- solib.h 1999/09/09 00:38:38 1.1.1.1 +++ solib.h 2000/03/07 21:55:11 1.2 @@ -37,6 +37,14 @@ clear_solib PARAMS ((void)); extern void solib_add PARAMS ((char *, int, struct target_ops *)); +/* Called to check solib list consistency and dump symbols from + unloaded shared objects. */ + +#define SOLIB_VERIFY() solib_verify () + +extern void +solib_verify PARAMS ((void)); + /* Function to be called when the inferior starts up, to discover the names of shared libraries that are dynamically linked, the base addresses to which they are linked, and sufficient information to read in their symbols Index: infrun.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/infrun.c,v retrieving revision 1.1.1.6 retrieving revision 1.2 diff -u -p -r1.1.1.6 -r1.2 --- infrun.c 2000/03/07 18:42:13 1.1.1.6 +++ infrun.c 2000/03/07 21:55:11 1.2 @@ -2416,6 +2416,9 @@ handle_inferior_event (struct execution_ /* Switch terminal for any messages produced by breakpoint_re_set. */ target_terminal_ours_for_output (); +#ifdef SOLIB_VERIFY + SOLIB_VERIFY (); +#endif SOLIB_ADD (NULL, 0, NULL); target_terminal_inferior (); } >From rose@netcom.com Sat Apr 01 00:00:00 2000 From: Ken Rose To: davidwilliams@ozemail.com.au Cc: crossgcc@sourceware.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: gdbstubs library posted at sourceforge Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200001311640.IAA08446@netcom.com> X-SW-Source: 2000-q1/msg00077.html Content-length: 1433 David Williams wrote: >As far as I understand LGPL license (having read it several times now) as a >minimum if the LGPL gdbstub code is included in a product of mine then I have >to make the source for the gdbstub and the object code available so that users >can modify the stub code and re-link with the supplied objects to create a new >"executable". Making these available is not really a problem for me. I assume >referring the user to a suitable web site (of mine) where such source and >objects would be available would be satisfactory. The problem for my users is >then that the "executable" as such needs to be written into flash memory. To do >this the user would have to pull apart the device and then connect two pins on >the PCB and then use some other software running on a PC (not normally supplied >to the user) to download and program the flash memory with the new image. This >is normally done as a factory proceedure. How far do I have to go to meet LGPL >requirements??? There was an on-line discussion about three years ago (unfortunately, I've forgotten where,exactly) that Stallman got involved with. His opinion seemed to be that once you've provided the appropriate source & object code, you've done what the license requires. If the software then needs to be installed in a ROM in the middle of an ASIC, that's the user's problem, not yours. If he voids the warranty by doing it, that's his problem, too. >From kettenis@wins.uva.nl Sat Apr 01 00:00:00 2000 From: Mark Kettenis To: mark@codesourcery.com Cc: Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, donnte@microsoft.com, gdb@sourceware.cygnus.com Subject: Re: Regressions problem (200 failures) Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003021246.e22CkWL00549@delius.kettenis.local> References: <200003021010.LAA13693@reisser.regent.e-technik.tu-muenchen.de> <20000302023420H.mitchell@codesourcery.com> X-SW-Source: 2000-q1/msg00497.html Content-length: 1704 From: Mark Mitchell Date: Thu, 02 Mar 2000 02:34:20 -0800 >>>>> "Peter" == Peter Schauer writes: Peter> For practical debugging purposes (especially C++), the line Peter> number information (and thus the breakpoint) has to be put Peter> before the initialization code for local variables, so that Peter> we can debug object initialization. But the line number itself doesn't have to indicate the `{'; it could indicate the next line, if that's what GDB wants. This is more possible than it used to be since the C++ front-end now puts out whole functions at once, rather than processing a statement at a time. Still, it's non-trivial. The following might be relevant for this discussion: The comment on symtab.c:find_function_start_sal() says: /* Given a function symbol SYM, find the symtab and line for the start of the function. If the argument FUNFIRSTLINE is nonzero, we want the first line of real code inside the function. */ If you look at the implementation of find_function_start_sal() you'll see that it uses SKIP_PROLOGUE to skip over the function prologue if FUNFIRSTLINE is nonzero, and then chooses the next line after the prologue. So GDB shouldn't have any problems with line notes for the prologue. The implementation of SKIP_PROLOGUE for the i386 lives in i386-tdep.c:i386_skip_prologue(). According to the ChangeLog, this code has not been changed since early 1994 (Hi Peter!), and it is not unlikely that it has suffered some bit rot since then. Are the prologue's generated by GCC any different from those generated back in 1994? Mark >From johan.rydberg@netinsight.se Sat Apr 01 00:00:00 2000 From: Johan Rydberg To: gdb@sourceware.cygnus.com Subject: probelms with registers Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38C292EF.50B53C09@netinsight.se> X-SW-Source: 2000-q1/msg00547.html Content-length: 682 Hi! I'm developing a "gdb-simulator" for a CPU, and it seems to work pretty good. But I have some questions. When I try to display the registers it says everyone except the link register is unavailable. Why this? It also fetches the PC register, but it also says it's unavailable. And, how do I from gdb call the `sim_info´ function? Right now I have implemented a "sim info" command, but since it's defined in the simulator interface I guess that there's a better way to do this. regards, Johan. -- Johan Rydberg johan.rydberg@netinsight.net Net Insight AB, Sweden direct: +46-8-685 04 17 http://www.netinsight.net phone: +46-8-685 04 00 fax: +46-8-685 04 20 >From kingdon@redhat.com Sat Apr 01 00:00:00 2000 From: Jim Kingdon To: gdb@sourceware.cygnus.com Subject: Re: unloading shared objects Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: References: <200003131759.SAA07581@reisser.regent.e-technik.tu-muenchen.de> X-SW-Source: 2000-q1/msg00697.html Content-length: 1875 > At present, GDB assumes that we know the shared object's load address > when we read the symbols. Perhaps this is a poor assumption, but it > is pretty fundamental to the current symbol table structure. I'm not > going to fix that as part of this dlclose change. Well, objfile_relocate was written to address this. But I agree, trying to fix this as part of the dlclose fix could be biting off more than is warranted. > - free_objfile calls CLEAR_SOLIB, which isn't what we want, I think. Ouch. That looks really bad. I suspect the CLEAR_SOLIB call can and should be moved up to symbol_file_command (note the call to SOLIB_RESTART - currently vestigial at least on Linux - which relates to the issue of whether to nuke all the shared library symbols on every run of the program). > - Selecting a core file and attaching to a process both add the shared > libraries' sections to the target_ops structure. When we unload a > shared library, we close the BFD those sections refer to. We > need to remove those sections from the target_ops structure. You noticed that one too, eh? ;-). > - Should solib.c be maintaining its own list of shared objects at all, > or should it always retrieve the full link map from the inferior, > and use the objfile list itself as our record of what we know about? Haven't looked at the code long enough to have a really good feel for this, but I think you are probably right. That your changes to nuke find_solib separate out the inferior access code enough to make the above practical. Anyway, thanks for writing this code and let me know if there is anything else I can do (at the moment, various ideas and encouragement seem like a better way for me to help than writing code - not only was my solib.c code somewhat buggy/unpopular, but I didn't really enjoy writing it either :-)). >From hjl@valinux.com Sat Apr 01 00:00:00 2000 From: "H . J . Lu" To: gdb-patches@sourceware.cygnus.com Cc: GDB Subject: A patch for gnu-regex Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <20000307134103.A20533@valinux.com> X-SW-Source: 2000-q1/msg00568.html Content-length: 10618 I believe gnu-regex is maintained in glibc 2. I'd like to use the one in glibc 2 instead of the one in gdb. H.J. --- 2000-03-07 H.J. Lu * config/alpha/alpha-linux.mh (REGEX, REGEX1): Clear. * config/i386/linux.mh: Likewise. * config/m68k/linux.mh: Likewise. * config/powerpc/linux.mh: Likewise. * config/sparc/linux.mh: Likewise. * config/alpha/alpha-linuxlibc1.mh: New. * config/i386/linuxlibc1.mh: Likewise. * config/powerpc/linuxlibc1.mh: Likewise. * config/sparc/linuxlibc1.mh: Likewise. * configure.host (alpha*-*-linux*libc1): New host. (i[3456]86-*-linux*libc1): Likewise. (i[3456]86-*-linux*libc5): Likewise. (powerpc-*-linux*libc1): Likewise. (sparc-*-linux*libc1): Likewise. (sparc-*-linux*libc5): Likewise. * irix5-nat.c: Include instead of "gnu-regex.h" for glibc 2. * monitor.c: Likewise. * osfsolib.c: Likewise. * solib.c: Likewise. * source.c: Likewise. * symtab.c: Likewise. Index: config/alpha/alpha-linux.mh =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/config/alpha/alpha-linux.mh,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 alpha-linux.mh --- config/alpha/alpha-linux.mh 2000/03/07 18:42:19 1.1.1.3 +++ config/alpha/alpha-linux.mh 2000/03/07 18:44:07 @@ -1,4 +1,9 @@ # Host: Little-endian Alpha running Linux + +# We should use the one in glibc 2. +REGEX= +REGEX1= + XDEPFILES= ser-tcp.o XM_FILE= xm-alphalinux.h NAT_FILE= nm-linux.h Index: config/i386/linux.mh =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/config/i386/linux.mh,v retrieving revision 1.1.1.2 retrieving revision 1.2 diff -u -p -r1.1.1.2 -r1.2 --- config/i386/linux.mh 2000/01/18 17:07:18 1.1.1.2 +++ config/i386/linux.mh 2000/03/07 21:31:30 1.2 @@ -1,10 +1,14 @@ # Host: Intel 386 running GNU/Linux +# We should use the one in glibc 2. +REGEX= +REGEX1= + XM_FILE= xm-linux.h XDEPFILES= ser-tcp.o NAT_FILE= nm-linux.h NATDEPFILES= infptrace.o solib.o inftarg.o fork-child.o corelow.o \ - core-aout.o i386v-nat.o i386-linux-nat.o linux-thread.o lin-thread.o + core-aout.o i386-linux-nat.o linux-thread.o lin-thread.o LOADLIBES = -ldl -rdynamic Index: config/m68k/linux.mh =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/config/m68k/linux.mh,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 linux.mh --- config/m68k/linux.mh 2000/01/18 17:07:22 1.1.1.2 +++ config/m68k/linux.mh 2000/01/18 17:08:57 @@ -1,5 +1,9 @@ # Host: Motorola m68k running Linux +# We should use the one in glibc 2. +REGEX= +REGEX1= + XM_FILE= xm-linux.h XDEPFILES= ser-tcp.o Index: config/powerpc/linux.mh =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/config/powerpc/linux.mh,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 linux.mh --- config/powerpc/linux.mh 2000/03/07 18:42:23 1.1.1.2 +++ config/powerpc/linux.mh 2000/03/07 18:44:08 @@ -1,5 +1,9 @@ # Host: PowerPC, running Linux +# We should use the one in glibc 2. +REGEX= +REGEX1= + XM_FILE= xm-linux.h XDEPFILES= ser-tcp.o XM_CLIBS= Index: config/sparc/linux.mh =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/config/sparc/linux.mh,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 linux.mh --- config/sparc/linux.mh 2000/01/18 17:07:30 1.1.1.2 +++ config/sparc/linux.mh 2000/01/18 17:08:58 @@ -1,4 +1,9 @@ # Host: Sparcstation, running Linux + +# We should use the one in glibc 2. +REGEX= +REGEX1= + XDEPFILES= ser-tcp.o XM_FILE= xm-linux.h NAT_FILE= nm-linux.h Index: configure.host =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/configure.host,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 configure.host --- configure.host 2000/01/18 17:06:53 1.1.1.2 +++ configure.host 2000/01/18 17:08:52 @@ -34,6 +34,7 @@ a29k-*-*) gdb_host=ultra3 ;; alpha*-*-osf1*) gdb_host=alpha-osf1 ;; alpha*-*-osf2*) gdb_host=alpha-osf2 ;; alpha*-*-osf[3456789]*) gdb_host=alpha-osf3 ;; +alpha*-*-linux*libc1) gdb_host=alpha-linuxlibc1 ;; alpha*-*-linux*) gdb_host=alpha-linux ;; arm*-*-linux*) gdb_host=linux ;; @@ -60,6 +61,8 @@ i[3456]86-*-freebsd*) gdb_host=fbsd ;; i[3456]86-*-netbsd*) gdb_host=nbsd ;; i[3456]86-*-go32*) gdb_host=go32 ;; i[3456]86-*-msdosdjgpp*) gdb_host=go32 ;; +i[3456]86-*-linux*libc1|i[3456]86-*-linux*libc5) + gdb_host=linuxlibc1 ;; i[3456]86-*-linux*) gdb_host=linux ;; i[3456]86-*-lynxos*) gdb_host=i386lynx ;; i[3456]86-*-mach3*) gdb_host=i386m3 ;; @@ -134,6 +137,7 @@ ns32k-utek-sysv*) gdb_host=merlin ;; powerpc-*-aix*) gdb_host=aix ;; powerpcle-*-cygwin*) gdb_host=cygwin ;; powerpcle-*-solaris*) gdb_host=solaris ;; +powerpc-*-linux*libc1) gdb_host=linuxlibc1 ;; powerpc-*-linux*) gdb_host=linux ;; # OBSOLETE pn-*-*) gdb_host=pn ;; @@ -146,6 +150,8 @@ rs6000-*-lynxos*) gdb_host=rs6000lynx ;; rs6000-*-aix4*) gdb_host=aix4 ;; rs6000-*-*) gdb_host=rs6000 ;; +sparc-*-linux*libc1|sparc-*-linux*libc5) + gdb_host=linuxlibc1 ;; sparc-*-linux*) gdb_host=linux ;; sparc-*-lynxos*) gdb_host=sparclynx ;; sparc-*-netbsdelf*) gdb_host=nbsdelf ;; Index: irix5-nat.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/irix5-nat.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 irix5-nat.c --- irix5-nat.c 1999/11/19 23:38:46 1.1.1.3 +++ irix5-nat.c 1999/11/19 23:40:52 @@ -278,10 +278,14 @@ fetch_core_registers (core_reg_sect, cor #include "objfiles.h" #include "command.h" #include "frame.h" -#include "gnu-regex.h" #include "inferior.h" #include "language.h" #include "gdbcmd.h" +#if defined __GLIBC__ && __GLIBC__ >= 2 +#include +#else +#include "gnu-regex.h" +#endif /* The symbol which starts off the list of shared libraries. */ #define DEBUG_BASE "__rld_obj_head" Index: monitor.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/monitor.c,v retrieving revision 1.1.1.5 diff -u -p -r1.1.1.5 monitor.c --- monitor.c 2000/03/07 18:42:14 1.1.1.5 +++ monitor.c 2000/03/07 18:44:06 @@ -50,9 +50,13 @@ #include "monitor.h" #include "gdbcmd.h" #include "inferior.h" -#include "gnu-regex.h" #include "dcache.h" #include "srec.h" +#if defined __GLIBC__ && __GLIBC__ >= 2 +#include +#else +#include "gnu-regex.h" +#endif static char *dev_name; static struct target_ops *targ_ops; Index: osfsolib.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/osfsolib.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 osfsolib.c --- osfsolib.c 1999/11/19 23:38:50 1.1.1.3 +++ osfsolib.c 1999/11/19 23:40:52 @@ -36,10 +36,14 @@ #include "command.h" #include "target.h" #include "frame.h" -#include "gnu-regex.h" #include "inferior.h" #include "language.h" #include "gdbcmd.h" +#if defined __GLIBC__ && __GLIBC__ >= 2 +#include +#else +#include "gnu-regex.h" +#endif #define MAX_PATH_SIZE 1024 /* FIXME: Should be dynamic */ Index: solib.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v retrieving revision 1.1.1.4 diff -u -p -r1.1.1.4 solib.c --- solib.c 2000/03/07 18:42:17 1.1.1.4 +++ solib.c 2000/03/07 21:32:29 @@ -49,11 +49,15 @@ #include "command.h" #include "target.h" #include "frame.h" -#include "gnu-regex.h" #include "inferior.h" #include "environ.h" #include "language.h" #include "gdbcmd.h" +#if defined __GLIBC__ && __GLIBC__ >= 2 +#include +#else +#include "gnu-regex.h" +#endif #define MAX_PATH_SIZE 512 /* FIXME: Should be dynamic */ Index: source.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/source.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 source.c --- source.c 2000/02/04 20:21:58 1.1.1.3 +++ source.c 2000/02/04 21:36:33 @@ -33,11 +33,15 @@ #include "gdb_stat.h" #include #include "gdbcore.h" -#include "gnu-regex.h" #include "symfile.h" #include "objfiles.h" #include "annotate.h" #include "gdbtypes.h" +#if defined __GLIBC__ && __GLIBC__ >= 2 +#include +#else +#include "gnu-regex.h" +#endif #ifdef UI_OUT #include "ui-out.h" #endif Index: symtab.c =================================================================== RCS file: /work/cvs/gnu/gdb/gdb/symtab.c,v retrieving revision 1.1.1.4 diff -u -p -r1.1.1.4 symtab.c --- symtab.c 2000/03/07 18:42:17 1.1.1.4 +++ symtab.c 2000/03/07 18:44:06 @@ -30,7 +30,6 @@ #include "objfiles.h" #include "gdbcmd.h" #include "call-cmds.h" -#include "gnu-regex.h" #include "expression.h" #include "language.h" #include "demangle.h" @@ -43,6 +42,11 @@ #include "gdb_string.h" #include "gdb_stat.h" #include +#if defined __GLIBC__ && __GLIBC__ >= 2 +#include +#else +#include "gnu-regex.h" +#endif /* Prototype for one function in parser-defs.h, instead of including that entire file. */ --- /dev/null Tue May 5 13:32:27 1998 +++ config/alpha/alpha-linuxlibc1.mh Tue Oct 19 09:50:12 1999 @@ -0,0 +1,10 @@ +# Host: Little-endian Alpha running Linux with the GNU C library 1. + +XDEPFILES= +XM_FILE= xm-alphalinux.h +NAT_FILE= nm-linux.h +NATDEPFILES= infptrace.o inftarg.o corelow.o core-regset.o alpha-nat.o \ + fork-child.o solib.o + +MMALLOC = +MMALLOC_CFLAGS = -DNO_MMALLOC --- /dev/null Tue May 5 13:32:27 1998 +++ config/i386/linuxlibc1.mh Tue Oct 19 09:50:21 1999 @@ -0,0 +1,8 @@ +# Host: Intel 386 running GNU/Linux with the Linux C library 5. + +XM_FILE= xm-linux.h +XDEPFILES= ser-tcp.o + +NAT_FILE= nm-linux.h +NATDEPFILES= infptrace.o solib.o inftarg.o fork-child.o corelow.o \ + core-aout.o core-regset.o i386lnx-nat.o lnx-thread.o lnx-nat.o --- /dev/null Tue May 5 13:32:27 1998 +++ config/powerpc/linuxlibc1.mh Tue Mar 7 13:35:15 2000 @@ -0,0 +1,10 @@ +# Host: PowerPC, running Linux with the GNU C library 1. + +XM_FILE= xm-linux.h +XDEPFILES= ser-tcp.o +XM_CLIBS= + +NAT_FILE= nm-linux.h +NATDEPFILES= infptrace.o solib.o inftarg.o fork-child.o corelow.o core-aout.o core-regset.o ppc-linux-nat.o linux-thread.o + +GDBSERVER_DEPFILES= low-linux.o --- /dev/null Tue May 5 13:32:27 1998 +++ config/sparc/linuxlibc1.mh Tue Oct 19 09:53:46 1999 @@ -0,0 +1,9 @@ +# Host: Sparcstation, running Linux with the Linux C library 5. + +XDEPFILES= ser-tcp.o +XM_FILE= xm-linux.h +NAT_FILE= nm-linux.h +NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o \ + core-regset.o sparc-nat.o +HOST_IPC=-DBSD_IPC +GDBSERVER_DEPFILES= low-sparc.o >From muller@cerbere.u-strasbg.fr Sat Apr 01 00:00:00 2000 From: Pierre Muller To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: RFD: New command to inspect other selectors memory. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003030843.JAA12246@cerbere.u-strasbg.fr> References: <200003021432.PAA01976@cerbere.u-strasbg.fr> <200003021347.OAA01051@cerbere.u-strasbg.fr> <200003021257.NAA00259@cerbere.u-strasbg.fr> X-SW-Source: 2000-q1/msg00515.html Content-length: 1161 I inserted this in a reply about pascal extension, but as I got no answer, I thought I will send it as a separate message. I have written for DJGPP target a relatively small patch. It allows to read memory from another selector this was very useful for me when I tried to debug the debugger itself and when I added exception support fro GDB on DJGPP ! This patch consists of the addition of one command that I called "xx" which is a simple clone of the "x" command but can take a selector as for intance "xx $fs:0x400" then the next "xx 0x800" keeps using the last selector value. I do not know if this could be interesting for other i386 targets (maybe for win32 to be able to see the content of the $fs selector that contains the exception chain, but I am not sure how if its readable inside a win32 API program). Is such kind of patch too specific to have any chance to get accepted ? I don't know if it could be of any use for other processors or operating system !! Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99 >From mirko.viviani@rccr.cremona.it Sat Apr 01 00:00:00 2000 From: mirko.viviani@rccr.cremona.it To: gdb@sourceware.cygnus.com Subject: gdb-cvs fails on freebsd-elf Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200003312231.AAA27172@rccr1.rccr.cremona.it> X-SW-Source: 2000-q1/msg00846.html Content-length: 221 Ciao! I've noticed that gdb on cvs does not support (and does not compile w/o some changes) on FreeBSD-elf... Who is the FreeBSD maintainer ? Thanks. -- Bye, Mirko (NeXTmail, MIME)