This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Patching gdb 5.0 for XFree86 module support


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]