Re: Patching gdb 5.0 for XFree86 module support

["Mike A. Harris" <mharris at redhat dot com>]

On Tue, 25 Sep 2001, Kevin Buettner wrote:

>> > --- 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.

My apologies for not answering right away, email mixup...

>I agree with Daniel.  I think it's going to be difficult to get the
>symtab maintainers to agree to this change.

Thats ok, I'll explain below.

>I'm curious about why it was needed in the first place though.
>SOFUN_ADDRESS_MAYBE_MISSING is alread defined for Linux.  Is it
>needed for some other (non-Linux) platform?

XFree86 runs on many platforms.  I am only concerned with being
able to debug XFree86 in Linux on our supported architectures 
personally though.  But if it needs that, and it only works on 
Linux, then those using other OS's wont be able to benefit.


>Hmm...  it just occurred to me that SOFUN_ADDRESS_MAYBE_MISSING needs
>to be multiarched.  Once that's done, your problem is solved since
>this could be turned on or off at will.

Sounds good to me.  Do you have any suggestion for how that 
should be done properly?

Ok, here is my explanation from above...

I've got two different goals in mind:

1) Having a build of gdb that can debug a modular XFree86 - even 
   if the code is crap and written in a bad way.  Just as long as 
   it works I am happy, even if it only works on x86.  I'll call 
   this my "I can use it now to get more work done quicker" 
   build.  ie: short term hack solution

2) If possible, having the functionality added to official gdb to
   do this in a technically 'proper' way that is clean and 
   likely not even XFree86 specific.  Again, primarily working on 
   Linux x86 minimum, but even better if it works on 
   axp/ia64/sparc, etc..  Being in mainstream gdb would allow 
   more joe blow's to debug X that wouldn't ordinarily bother to 
   jump through the hoops necessary now due to XFree86's oddball 
   nature.  This is more of a longterm solution.

If #2 is not difficult and could be done fairly easily by 
someone, or if someone could guide me as to how to go about it 
(keeping in mind I really know ziltch about gdb internals), that 
would be great.  I don't know the compexity involved so I can't 
guage how much I would be getting in over my head on this.

If #2 doesn't stand much chance of happening in the short term, 
if someone could help me hack some nasty 'code you never want 
your Mom to see' up (like the junk I posted already <grin>), or 
offer any advice on how I could conk what I have with a 12 pound 
sledge to get it to work for the interim, that would be a really 
big help to me.

Thanks for the advice guys!
Take care,
TTYL

----------------------------------------------------------------------
Mike A. Harris                  Shipping/mailing address:
OS Systems Engineer             190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer              Ontario, Canada, P6C 5B3
Red Hat Inc.                    Phone: (705)949-2136
http://www.redhat.com           ftp://people.redhat.com/mharris

Red Hat XFree86 mailing list:   xfree86-list@redhat.com
General open IRC discussion:    #xfree86 on irc.openprojects.org
----------------------------------------------------------------------
root@dod.usarmy.gov:~#  rm -f /bin/laden