From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8288 invoked by alias); 7 Oct 2003 04:43: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 8280 invoked from network); 7 Oct 2003 04:43:36 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 7 Oct 2003 04:43:36 -0000 Received: by zenia.home (Postfix, from userid 5433) id 538A920766; Mon, 6 Oct 2003 23:42:23 -0500 (EST) To: Roland McGrath Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO References: <200310062024.h96KODfk030392@magilla.sf.frob.com> From: Jim Blandy Date: Tue, 07 Oct 2003 04:43:00 -0000 In-Reply-To: <200310062024.h96KODfk030392@magilla.sf.frob.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00162.txt.bz2 Roland McGrath writes: > > I think you can rely on SOLIB_ADD not being called too early. It would > > be a bug if we ever called it before the shell execs the executable under > > debug, because we use the VMA of the .dynamic section of the executable > > file to find the dynamic structure in the inferior's memory anyway. We > > couldn't even find the shell's shared library list. > > Right, it would fail to find any list at all. If it treats that as "empty > list" then this won't be a change from before and so it's a harmless no-op. > Are we sure that is not what is happening now? If it is, it's harmless now > but having the auxv-reading done too early would not be harmless. Well, child_create_inferior calls fork_inferior, passing ptrace_him as the init_trace_fun. ptrace_him calls startup_inferior to get past the shell. startup_inferior uses 'resume' to get past the various traps that occur before we reach the actual program under debug; resume, unlike proceed (gotta love it) does not insert breakpoints, and thus will never yield BPSTAT_WHAT_CHECK_SHLIBS, and thus will never call SOLIB_ADD. I verified this by actually starting up a program and watching things happen. So, yes, we're sure. Happy? :) (To be honest, I'm never sure of much when dealing with the program startup and event analysis code...) > > I disagree with moving the read of auxv to bfd. Gdb already processes > > plenty of /proc files (on Solaris using 2 interfaces), and has target > > methods defined for these, so I would treat the auxv case just like the > > others. > > What we have been discussing most recently is only a BFD utility function > to examine raw auxv blocks that have already been read in somehow. > i.e., a trivial helper function that these target methods would use. > It doesn't matter to me whether this is in bfd/elf.c or gdb/elfread.c. I can see going either way. The code in question just does a bit of grunging with ElfNN_External_Auxv and ElfNN_Internal_Auxv, but has no contact with other GDB stuff, so I figured it should go in BFD. The involvement of /proc wasn't really at issue --- when you're processing cores, it isn't involved at all.