From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20881 invoked by alias); 11 Aug 2005 22:23:37 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20546 invoked by uid 22791); 11 Aug 2005 22:23:26 -0000 Received: from s142-179-108-108.bc.hsia.telus.net (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 11 Aug 2005 22:23:26 +0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 351B847E74; Thu, 11 Aug 2005 15:23:23 -0700 (PDT) Date: Thu, 11 Aug 2005 23:54:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFC] link GDB against libunwind-ia64 Message-ID: <20050811222323.GO10325@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2005-08/txt/msg00122.txt.bz2 Hello, I'm currently working on a GDB port for ia64-hpux, and I'm having some problems with the unwinding of a stacked register. I'm trying to find the source of the problem, and part of the investigation lead me to look into the libunwind-ia64 code. I noticed that GDB uses the libunwind-ia64 shared library without being directly linked to it. Instead, it uses dlopen(). This method has its advantages, but also introduces an extra layer of complication that is preventing me from making progress (*): A bug in my debugger is causing problems when I am attempting operations such as next or step over code inside that library. So I'd like to add an option so that GDB is explicitly linked against libunwind-ia64, instead of using dlopen(). As a bonus, this may simplify our work in terms of binary distribution... I was wondering if this would be an interesting enhancement to contribute. Let me know... -- Joel (*): There is also the fact that it's tough to tell when you run GDB whether the libunwind unwinder has been initialized or not, since it depends on the success of the dlopen() and a few other operations. And when succesful, it's also tough to determine which one was used.