From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: GDB Patches <gdb-patches@sourceware.org>, Tom Tromey <tromey@redhat.com>
Subject: Re: [PATCH] Sanitize gdbarch access on probe/SDT API
Date: Fri, 06 Dec 2013 13:50:00 -0000 [thread overview]
Message-ID: <52A1D61E.1050707@redhat.com> (raw)
In-Reply-To: <m361r3hrrf.fsf_-_@redhat.com>
> I tried to use get_selected_frame whenever I could, and when I couldn't,
> I used get_current_regcache.
But what does "couldn't" mean?
Looking at the function that uses get_current_regcache:
On 12/05/2013 10:12 PM, Sergio Durigan Junior wrote:
> @@ -1461,6 +1466,8 @@ stap_get_probes (VEC (probe_p) **probesp, struct objfile *objfile)
> bfd_vma base;
> struct sdt_note *iter;
> unsigned save_probesp_len = VEC_length (probe_p, *probesp);
> + struct regcache *regcache = get_current_regcache ();
> + struct gdbarch *gdbarch = get_regcache_arch (regcache);
AFAICS, stap_get_probes isn't called when evaluating a probe,
but instead when getting the list of probes out of an objfile.
Seems to me like this function is reachable even if the inferior
is not running yet. Is that why you couldn't use
get_selected_frame here? (because there's no frame?) If so,
using get_current_regcache is wrong. If there's no thread at
all, then what does the regcache of the current thread mean?
It sounds like you just managed to use it becauese
get_current_regcache doesn't error out when inferior_ptid
is pointing nowhere. As this is listing the probes in
the objfile, and not using the target's registers (afaics),
can you use the objfile's arch here? With that out of the way,
would it work to pass the frame pointer down instead of the
gdbarch?
> if (objfile->separate_debug_objfile_backlink != NULL)
> {
> @@ -1486,7 +1493,7 @@ stap_get_probes (VEC (probe_p) **probesp, struct objfile *objfile)
> {
> /* We first have to handle all the information about the
> probe which is present in the section. */
> - handle_stap_probe (objfile, iter, probesp, base);
> + handle_stap_probe (objfile, iter, probesp, base, gdbarch);
> }
--
Pedro Alves
next prev parent reply other threads:[~2013-12-06 13:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-05 6:34 [PATCH] Use "get_current_arch" instead of "get_objfile_arch" on SystemTap SDT code (and fix ARM bug) Sergio Durigan Junior
2013-12-05 13:04 ` Pedro Alves
2013-12-05 22:12 ` [PATCH] Sanitize gdbarch access on probe/SDT API (was: Re: [PATCH] Use "get_current_arch" instead of...) Sergio Durigan Junior
2013-12-05 23:06 ` [PATCH] Sanitize gdbarch access on probe/SDT API Sergio Durigan Junior
2013-12-05 23:30 ` Tom Tromey
2013-12-06 2:22 ` Sergio Durigan Junior
2013-12-06 13:50 ` Pedro Alves [this message]
2013-12-06 15:49 ` Sergio Durigan Junior
2013-12-06 16:00 ` Pedro Alves
2013-12-06 16:04 ` Sergio Durigan Junior
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=52A1D61E.1050707@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=sergiodj@redhat.com \
--cc=tromey@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