From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9133 invoked by alias); 13 Aug 2002 17:46:47 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9102 invoked from network); 13 Aug 2002 17:46:45 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 13 Aug 2002 17:46:45 -0000 Received: from porcupine.slc.redhat.com (vpn3-4.sfbay.redhat.com [172.16.25.4]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA28290; Tue, 13 Aug 2002 10:43:10 -0700 (PDT) Received: from porcupine (law@localhost) by porcupine.slc.redhat.com (8.11.6/8.11.6) with ESMTP id g7DHoN309354; Tue, 13 Aug 2002 11:50:24 -0600 Message-Id: <200208131750.g7DHoN309354@porcupine.slc.redhat.com> To: ross.alexander@uk.neceur.com cc: binutils@sources.redhat.com, gdb@sources.redhat.com Reply-To: law@redhat.com Subject: Re: PA64 shared library problems with gdb-5.2 (hpux) In-Reply-To: Your message of "Tue, 13 Aug 2002 17:12:41 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 10:46:00 -0000 From: Jeff Law X-SW-Source: 2002-08/txt/msg00119.txt.bz2 In message , 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