From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3758 invoked by alias); 26 May 2011 17:02:30 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 3744 invoked by uid 22791); 26 May 2011 17:02:28 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Date: Thu, 26 May 2011 17:02:00 -0000 From: Gary Benson To: archer@sourceware.org Subject: Re: Improved linker-debugger interface Message-ID: <20110526170207.GA2830@redhat.com> Mail-Followup-To: archer@sourceware.org References: <20110525153649.GB3149@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SW-Source: 2011-q2/txt/msg00002.txt.bz2 Tom Tromey wrote: > Gary> I've attached a patch for glibc that implements its side of > Gary> the interface, designed to apply after the SystemTap support > Gary> that was added for F15, so if what I've written doesn't make > Gary> sense then maybe at least the code will! > > Gary> Does this all seem ok? > > It makes sense as far as I understand it. I don't know glibc very > well. I'd suggest asking Andreas Schwab for a review. Cool, I'll mail him. > Gary> +void > Gary> +_dl_debug_state_extended (Lmid_t ns, struct r_debug *r) > Gary> +{ > Gary> + if (r->r_state == RT_CONSISTENT) > Gary> + { > Gary> + LIBC_PROBE (r_debug_mod_complete, 2, ns, r); > Gary> + } > Gary> + else > Gary> + { > Gary> + LIBC_PROBE (r_debug_mod_starting, 2, ns, r); > Gary> + } > > Will 'ns' give gdb enough information to do its work in the dlmopen > case? Or will we want gdb to have access to some other thing? I am > wondering Lmid_t is just some internal-to-glibc cookie, where gdb > will actually want a pointer to some ld.so data structure. I don't > actually know anything about this though. The way glibc handles multiple namespaces is to have a separate r_debug structure for each one. The problem is that the current interface only has provision for exposing one of these to the debugger, so gdb can only see the initial namespace. The "r" argument to the probe is the r_debug structure for the namespace being modified. The "ns" argument isn't internal (at least, I don't think it is). It's the argument you pass to dlmopen to tell it which namespace to load the library into: extern void *dlmopen (Lmid_t nsid, const char *file, int mode); It might be internal, though. There are two special values, LM_ID_BASE (load into the initial namespace) and LM_ID_NEWLM (create a new namespace and load into that). It may be that these are the only values external code should call. I couldn't see any obvious way of discovering the namespace id of a loaded object so you could then load other things into it, but I haven't looked exhaustively. Anyway, the "ns" argument isn't enough for gdb to work on, but the "r" argument is. I put them both into the probe because gdb will probably have to maintain some internal list and the "ns" argument would be useful to track them against (and maybe get displayed in a column in "info shared"). Cheers, Gary -- http://gbenson.net/