From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32331 invoked by alias); 4 Oct 2003 23:28:36 -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 32324 invoked from network); 4 Oct 2003 23:28:35 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 4 Oct 2003 23:28:35 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A5vpD-0007ek-CT; Sat, 04 Oct 2003 19:28:35 -0400 Date: Sat, 04 Oct 2003 23:28:00 -0000 From: Daniel Jacobowitz To: Roland McGrath Cc: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO Message-ID: <20031004232835.GA2853@nevyn.them.org> Mail-Followup-To: Roland McGrath , Jim Blandy , gdb-patches@sources.redhat.com References: <20031004211441.GA24371@nevyn.them.org> <200310042201.h94M19l9028218@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310042201.h94M19l9028218@magilla.sf.frob.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00093.txt.bz2 On Sat, Oct 04, 2003 at 03:01:09PM -0700, Roland McGrath wrote: > > Yes, since this is when solibs are normally loaded anyway. > > Ok. I was concerned that it might just try to look at the shell, where its > symbols wouldn't match and it would just ignore those errors. Getting the > auxv information will always work, but could be wrong information if there > is another exec, so that would not be as resilient as SOLIB_ADD now is. > To wit, infrun.c:1352: > > case TARGET_WAITKIND_LOADED: > /* Ignore gracefully during startup of the inferior, as it > might be the shell which has just loaded some objects, > otherwise add the symbols for the newly loaded objects. */ > > If this comment is accurate and I'm understanding its context correctly, > the problem I just described is in fact a problem. It is not accurate. TARGET_WAITKIND_LOADED isn't currenty used for non HP/UX targets. > > An issue is whether it gets called early enough, i.e. before the > > dynamic linker breakpoint is hit, or at all for static applications. > > We'll have to see. > > Indeed, it doesn't look to me like it is, except for the attach case. > Aside from attach_command, all the SOLIB_ADD calls in infrun.c are > conditional on some kind of "shlib loaded" event. I am presuming those > don't happen at exec. We don't want to SOLIB_ADD before the dynamic linker has gotten a chance to initialize, I suspect. Let me think about it; let's fix the dynamic case first. > Incidentally, I'm also noticing another case we haven't been discussing > directly. In addition to the core, attach, and run scenarios, there is > "follow exec" apparently. I ran across this in looking for the earliest > places insert_breakpoints is called, which seems like around the same time > the auxv examination and vsyscall DSO setup should be done. Don't worry about follow_exec. It's currently broken and needs some serious redesigning. I haven't had a chance to revisit this since I fixed fork following. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer