From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mike A. Harris" To: Kevin Buettner Cc: Daniel Jacobowitz , Subject: Re: Patching gdb 5.0 for XFree86 module support Date: Wed, 03 Oct 2001 23:45:00 -0000 Message-id: References: <1010925175232.ZM32001@ocotillo.lan> X-SW-Source: 2001-10/msg00079.html 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 ), 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