From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9847 invoked by alias); 18 Dec 2008 22:10:49 -0000 Received: (qmail 9837 invoked by uid 22791); 18 Dec 2008 22:10:49 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Dec 2008 22:10:08 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 413A31053D; Thu, 18 Dec 2008 22:10:06 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 17BCD10499; Thu, 18 Dec 2008 22:10:06 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1LDR4H-0002PG-CI; Thu, 18 Dec 2008 17:10:05 -0500 Date: Thu, 18 Dec 2008 22:10:00 -0000 From: Daniel Jacobowitz To: Mathieu Lacage Cc: gdb@sourceware.org Subject: Re: how to make gdb happy with my linkmap Message-ID: <20081218221005.GA9012@caradoc.them.org> Mail-Followup-To: Mathieu Lacage , gdb@sourceware.org References: <74fef6df0812181341x8ecdd31me028bd4d658384b1@mail.gmail.com> <20081218214854.GA7706@caradoc.them.org> <74fef6df0812181402n1debced5xbe3f402a3a34ecf2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74fef6df0812181402n1debced5xbe3f402a3a34ecf2@mail.gmail.com> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00086.txt.bz2 On Thu, Dec 18, 2008 at 11:02:22PM +0100, Mathieu Lacage wrote: > > On SVR4 systems, basically, you can't. There is some information you > > won't be able to update because it lives in the kernel (auxilliary > > vector). This is one of the reasons I recently implemented "set > > erm, I might be totally naive, but, how does the libc loader achieve > this then ? The only thing I am trying to do is be sufficiently > compatible with the libc loader to make gdb happy with my loader. Did > I mention that I am trying to replace the libc loader rather than try > to make two loaders co-exist in the same process image (which would > create another set of challenging problems from a compatibility > perspective). Oh! Sorry. Then I was off on a tangent. The salient difference is whether your loader is started by the kernel based on a PT_INTERP entry in the executable, or from the command line. If it's started by PT_INTERP, things are much easier to handle. The only things I can think of are having the main application first, and having the debug function be named _dl_debug_state (because we set a breakpoint before _r_debug is initialized). There's not much more to it. -- Daniel Jacobowitz CodeSourcery