From: Jim Blandy <jimb@redhat.com>
To: Roland McGrath <roland@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: unwind support for Linux 2.6 vsyscall DSO
Date: Mon, 06 Oct 2003 17:14:00 -0000 [thread overview]
Message-ID: <vt2brsuwapp.fsf@zenia.home> (raw)
In-Reply-To: <200310042027.h94KR6If023360@magilla.sf.frob.com>
Roland McGrath <roland@redhat.com> 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.
next prev parent reply other threads:[~2003-10-06 17:14 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-03 8:27 Roland McGrath
2003-10-03 23:44 ` Jim Blandy
2003-10-04 0:10 ` Roland McGrath
2003-10-04 7:28 ` Jim Blandy
2003-10-04 20:27 ` Roland McGrath
2003-10-04 21:14 ` Daniel Jacobowitz
2003-10-04 22:01 ` Roland McGrath
2003-10-04 23:28 ` Daniel Jacobowitz
2003-10-06 17:14 ` Jim Blandy [this message]
2003-10-06 19:35 ` Elena Zannoni
2003-10-06 19:31 ` Elena Zannoni
2003-10-06 20:24 ` Roland McGrath
2003-10-06 21:48 ` Elena Zannoni
2003-10-06 23:59 ` Roland McGrath
2003-10-07 0:13 ` Roland McGrath
2003-10-07 2:30 ` Elena Zannoni
2003-10-07 2:40 ` Roland McGrath
2003-10-07 2:47 ` Roland McGrath
2003-10-07 3:53 ` Andrew Cagney
2003-10-07 4:07 ` Daniel Jacobowitz
2003-10-07 4:17 ` Andrew Cagney
2003-10-07 4:28 ` Roland McGrath
2003-10-08 0:02 ` Michael Snyder
2003-10-08 0:46 ` Roland McGrath
2003-10-08 18:27 ` Andrew Cagney
2003-10-08 21:00 ` Andrew Cagney
2003-10-08 21:47 ` Roland McGrath
2003-10-08 23:25 ` Elena Zannoni
2003-10-09 0:45 ` Roland McGrath
2003-10-08 23:10 ` Elena Zannoni
2003-10-09 0:50 ` Roland McGrath
2003-10-08 23:53 ` Daniel Jacobowitz
2003-10-07 0:17 ` Daniel Jacobowitz
2003-10-07 23:54 ` Michael Snyder
2003-10-08 0:07 ` Roland McGrath
2003-10-07 4:43 ` Jim Blandy
2003-10-07 4:45 ` Roland McGrath
2003-10-09 19:58 ` Kevin Buettner
2003-10-09 20:02 ` Daniel Jacobowitz
2003-10-09 20:10 ` Jim Blandy
2003-10-09 22:20 ` Roland McGrath
2003-10-09 22:49 ` Kevin Buettner
2003-10-10 0:12 ` Michael Snyder
2003-10-11 1:44 ` Roland McGrath
2003-10-09 23:04 ` Kevin Buettner
2003-10-11 1:47 ` Roland McGrath
2003-10-15 4:33 ` Kevin Buettner
2003-10-09 20:21 ` Kevin Buettner
2003-10-09 20:23 ` Daniel Jacobowitz
2003-10-09 20:46 ` Kevin Buettner
2003-10-09 22:32 ` Roland McGrath
2003-10-09 22:46 ` Kevin Buettner
2003-10-11 1:40 ` Roland McGrath
2003-10-09 22:07 ` Roland McGrath
2003-10-09 22:32 ` Kevin Buettner
2003-10-07 3:33 Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vt2brsuwapp.fsf@zenia.home \
--to=jimb@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=roland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox