From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mike A. Harris" To: Kevin Buettner Cc: Andrew Cagney , Subject: Re: Patching gdb 5.0 for XFree86 module support Date: Tue, 25 Sep 2001 16:19:00 -0000 Message-id: References: <1010925174228.ZM31980@ocotillo.lan> X-SW-Source: 2001-09/msg00339.html On Tue, 25 Sep 2001, Kevin Buettner wrote: >> ... proposed similar things while making the observation that the current >> shlib implementation should be generalized. > >I've been giving this a bit of thought. Until now, it never occurred >to me that we'd want more than one shared library symbol loader active >simultaneously. For this kind of scenario (non-system library loaders), >I think it would be beneficial to extend GDB's shared lib machinery. > >Once this is done, support for the XFree86 loader will be possible >without needing to introduce a new breakpoint type. The changes to >infrun.c will also become unnecessary. Cool. >As to how to extend the solib machinery... > >It seems to me that current_target_so_ops could be changed to point at >a chain of target_so_ops structs. Each of the TARGET_SO_* macros >would be rewritten as functions to invoke the relevant method for each >backend in the chain. For methods which return values, the >TARGET_SO_* replacement functions would need to construct an >appropriate aggragate return value. (This is probably not as hard as >it sounds; e.g, TARGET_SO_IN_DYNSYM_RESOLVE_CODE would call the >in_dynsym_resolve_code method for each backend and return 1 (true) if >any of the backend code returned true. The only moderately tricky one >would be TARGET_SO_CURRENT_SOS(), but I don't see any great difficulty >with making this one work either.) A bit over my head, but I think I follow what you're saying as far as understanding what it will do - but not how to implement it. I'm not at all familiar with gdb source, and only took the old patch and munged it one hunk at a time to fit into gdb 5. Certain portions didn't make sense and wouldn't 'fit' so to speak, so I analyzed the code by hand in each case as best as I could, and massaged it to fit appropriately, at least that was the aim. Then fixed up numerous compiler errors, and warnings. IOW -> I code monkey'd it into working. I'm still not familiar enough with all the internals of gdb to fully grok what needs to change for it to work properly out of the box. Ultimately of course, I would love to see a generic solution that is integrated into gdb and just 'works' with XFree86 as well. Depending on how complex that would be to do though, I'd settle for a quick hack ontop of a hack on a hack though that "works for now(tm)". ;o) Your help is thus muchly appreciated, Thanks. 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 IRC: #redhat-xfree86 on irc.openprojects.org ---------------------------------------------------------------------- root@dod.usarmy.gov:~# rm -f /bin/laden