From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: "Mike A. Harris" Cc: gdb-patches@sources.redhat.com Subject: Re: Patching gdb 5.0 for XFree86 module support Date: Sun, 23 Sep 2001 10:42:00 -0000 Message-id: <20010923134204.A31683@nevyn.them.org> References: X-SW-Source: 2001-09/msg00308.html On Sun, Sep 23, 2001 at 09:27:00AM -0400, Mike A. Harris wrote: > When I started this the other day, I had never looked at gdb > source before, so bear with me. ;o) > > I first ported the patch to at least apply cleanly to current > source, making some guesses along the way when not 100% sure what > was correct. I've fixed all compilation warnings and all > compilation errors but one now, which I'm not yet sure how to > resolve as I'm not too familiar with gdb internals. Well, I don't know the solution to that problem off hand, but here's comments on two things that jumped out at me. > I'd be greatful for any suggestions anyone may have that help get > this working. Also, what is the best list for such discussion? Right here. > --- gdb/dbxread.c.xfree86-modules Sat Jul 7 13:19:50 2001 > +++ gdb/dbxread.c Sun Sep 23 07:53:12 2001 > @@ -2272,7 +2272,7 @@ > case 'F': > function_stab_type = type; > > -#ifdef SOFUN_ADDRESS_MAYBE_MISSING > +#if defined(SOFUN_ADDRESS_MAYBE_MISSING) || defined(XFREE_MODULE_SUPPORT) > /* Deal with the SunPRO 3.0 compiler which omits the address > from N_FUN symbols. */ > if (type == N_FUN I'm not sure that's going to fly. SOFUN_ADDRESS_MAYBE_MISSING introduces its own problems; there's a good discussion in the list archives but I can't find it at the moment. Of course, I can see why you'd need that segment. > --- gdb/xfreemod.c.xfree86-modules Sun Sep 23 07:53:12 2001 > +++ gdb/xfreemod.c Sun Sep 23 08:01:57 2001 > +/* The XFree server has its own dynamic load mechanism. Unlike shared > + * libraries it loads regular .o (or even .a) files. GDB support for > + * tracking loaded modules is very similar to shared libraries however > + * (in fact much of this code originated in solib.c). > + * > + * There are a few differences. We don't need to do very much in the > + * create_inferior hook as no modules are loaded at that point so we > + * just tidy up after the last run, tell the inferior that we're > + * around and insert a breakpoint so we get chance to do something > + * when a module is loaded. > + * > + */ Actually, CREATE_INFERIOR_HOOK seems to be called during remote attach. I'm not absolutely convinced that it should be, but it is - see remote.c (might post-date your RPM, I'm not sure). So this assumption may not be valid. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer