This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PA64 shared library problems with gdb-5.2 (hpux)
- From: Jeff Law <law at porcupine dot slc dot redhat dot com>
- To: ross dot alexander at uk dot neceur dot com
- Cc: binutils at sources dot redhat dot com, gdb at sources dot redhat dot com
- Date: Tue, 13 Aug 2002 11:50:23 -0600
- Subject: Re: PA64 shared library problems with gdb-5.2 (hpux)
- Reply-to: law at redhat dot com
In message <OFDB2CC141.AC015F00-ON80256C14.0055FF4D@uk.neceur.com>,
ross.alexander@uk.neceur.com writes:
>So it is something to do with the interaction with gdb's copy function.
I'm not sure what you mean by "gdb's copy function".
There are some differences in how we call dlgetmodinfo and dlgetname
that you might investigate as well.
We also pass our own function for reading memory as well as the load
map we extracted from the dynamic linker earlier. Your testcode doesn't
do that. Who knows, maybe that's the problem.
As a test you could probably change gdb to not pass in a memory read
function or the load map and see if that changes GDB's behavior in a
positive way.
You might also download the lastest wildebeast sources from HP and see
how it handles building the shared library list. Note their code is
probably different in significant ways from the code that's officially
in GDB. HP stopped contributing their changes back to the GDB project
long ago.
>to start. I might try to cross build a 64bit version of gdb as a
>32bit SOM exe, so I could then run that under a 32bit gdb,
>but I'm not sure if that will actually work.
It will work, but only if you go find one or two magic libraries that
HP doesn't provide by default -- those libraries provide the
dlgetmodinfo/dlgetname routines as 32bit SOM objects, but which
read data from the 64bit loader. You may be able to get them from HP's
wildebeast source/objects on the web.
jeff