Re: Patching gdb 5.0 for XFree86 module support

[Daniel Jacobowitz <drow at mvista dot com>]

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