From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26876 invoked by alias); 6 Oct 2003 17:14:53 -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 26849 invoked from network); 6 Oct 2003 17:14:49 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 6 Oct 2003 17:14:49 -0000 Received: by zenia.home (Postfix, from userid 5433) id B925120766; Mon, 6 Oct 2003 12:13:39 -0500 (EST) To: Roland McGrath Cc: gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO References: <200310042027.h94KR6If023360@magilla.sf.frob.com> From: Jim Blandy Date: Mon, 06 Oct 2003 17:14:00 -0000 In-Reply-To: <200310042027.h94KR6If023360@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/msg00108.txt.bz2 Roland McGrath writes: > > > Should this SOLIB_ADD then just store whether it has checked yet and clear > > > that record in SOLIB_CLEAR? > > > > I think that's what it would take. Open to better ideas, I'm just > > doing the best I can. :) > > Ok. I don't see a problem with this if the sequence of when SOLIB_ADD and > SOLIB_CLEAR will be called is correct. That is, SOLIB_ADD after core load, > after attach, or after the break-on-exec (second one) from run, and > SOLIB_CLEAR some appropriate time for unloading symbols. It's important > that SOLIB_ADD not be called too early in the run case, i.e. before the > second exec so that the inferior's state is not yet as it will be. > Can I rely on that not happening? 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. > > When I say "target vector", I mean 'struct target_ops', not 'struct > > gdbarch'. > > I understood you. My only point was that the notion of such a hook is > ELF-specific and so perhaps that says something about whether an addition > of a hook to the generic target_ops structure is appropriate. I'm wondering how the core / live process distinction gets made when we need to find the auxilliary vector. The code reading the vsyscall library from memory should just read memory from whatever target is there, and it seems like the aux vector should work the same way. > Ok. A function quite that specific seems really pointless to me. Some > sort of `bfd_elf_decode_auxv' that either gives an AT_* value to search > for, or translates one or all entries into Elf_Internal_Auxv format seems > more appropriate. e.g.: > > bfd_error bfd_elf_decode_auxv (bfd *, char **data, bfd_size_type *nbytes, > Elf_Internal_Auxv *element); > > used as in: > > { > Elf_Internal_Auxv av; > char *p = contents; > bfd_size_type n = contents_size; > while (bfd_elf_decode_auxv (abfd, &p, &n, &av) == bfd_error_no_error) > if (av.a_type == AT_SYSINFO_EHDR) > { > do_stuff (av.a_val); > break; > } > } > > or: > > bfd_error bfd_elf_auxv_extract (bfd *, char *data, bfd_size_type nbytes, > bfd_vma tag, bfd_vma *val); > > used as in: > > { > bfd_vma val; > if (bfd_elf_auxv_extract (abfd, contents, contents_size, > AT_SYSINFO_EHDR, &val) == bfd_error_no_error) > do_stuff (av.a_val); > } The latter seems nicer to me.