This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [commit] Improved linker-debugger interface
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, gdb-patches at sourceware dot org, Jan Kratochvil <jan dot kratochvil at redhat dot com>, Pedro Alves <palves at redhat dot com>
- Date: Wed, 26 Jun 2013 14:11:40 -0300
- Subject: Re: [commit] Improved linker-debugger interface
- References: <20130516144340 dot GA2105 at blade dot nx> <20130604133819 dot GA25892 at blade dot nx> <20130625205350 dot GA28973 at adacore dot com> <m3obatx5b3 dot fsf at redhat dot com> <87hagkrih3 dot fsf at fleche dot redhat dot com>
On Wednesday, June 26 2013, Tom Tromey wrote:
> It seems to me that we could make the warning more verbose and have it
> request that users file a bug report; and it could include a little
> explanation, plus some text to report. Like:
>
> warning: Probes-based dynamic linker interface failed:
> Unknown numeric token ...
> This means there is a bug, either in gdb or elsewhere in the
> toolchain. Please report it to the gdb bugzilla, along with
> this information:
> Arch: Whatever
> Probe name: ...
> Argument number: ...
> Argument text: ...
>
> Being extra wordy is a bit of a pain, maybe, since presumably users will
> see it often. OTOH, it's a "shouldn't happen" scenario where gdb has
> lots of information already...
Sounds good to me, but...
> Also, I wonder why we're trying to use the probes on a platform to which
> the gdb side hasn't been ported. Are we just optimistically trying to
> parse the assembly operands here?
That's a relevant question. GDB has a generic asm parser (implemented
in stap-probe.c), which makes use of specific target-dep
functions/variables to correctly handle the idiosyncrasies of each type
of asm.
So far, we have support for x86, x86_64, PPC, PPC64, ARM, and a pending
patch for IA-64. However, there must be more architectures where we
will need to implement it. The pre-requisite I am/was using is: if
systemtap-sdt-devel is installable on the system, then GDB needs to
support SDT probes. Unfortunately I failed to check IA-64, but that is
hopefully fixed now.
OTOH, if the user successfuly installs <sys/sdt.h> on her system, then
GDB should at least be prepared to avoid trying to parse something it
doesn't fully understand.
What could be done is to check gdbarch_stap_is_single_operand_p. This
is a mandatory function that needs to be set by the target. If it
doesn't exist, then we know that the target lacks SDT support.
Before I work on a patch, I'd like to know what you think.
Thanks,
--
Sergio