From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15346 invoked by alias); 4 Oct 2003 20:27:10 -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 15338 invoked from network); 4 Oct 2003 20:27:08 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 4 Oct 2003 20:27:08 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id AB0CB357B; Sat, 4 Oct 2003 13:27:07 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id h94KR7N2023364; Sat, 4 Oct 2003 13:27:07 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h94KR6If023360; Sat, 4 Oct 2003 13:27:06 -0700 Date: Sat, 04 Oct 2003 20:27:00 -0000 Message-Id: <200310042027.h94KR6If023360@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: Jim Blandy's message of , 4 October 2003 02:28:35 -0500 X-Zippy-Says: I'm having a BIG BANG THEORY!! X-SW-Source: 2003-10/txt/msg00089.txt.bz2 > > 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? > 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. > Yeah, I had in mind another elf-specific BFD function, like the one > that reads the solib data from memory. All I'm suggesting is, take > the code that you've got, move it into bfd, and call it > bfd_elf_auxilliary_vector_sysinfo_ehdr. 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); } Thanks, Roland