This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PA64 shared library problems with gdb-5.2 (hpux)


 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



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