From: Avi Gozlan <avi@checkpoint.com>
To: Avi Gozlan <avi@checkpoint.com>,
"'Tom Tromey'" <tromey@redhat.com>,
"'gdb-patches@sourceware.org'"
<gdb-patches@sourceware.org>
Cc: Matan Ben Gur <matanbg@checkpoint.com>
Subject: RE: Re: [RFC] canonical linespec and multiple breakpoints ...
Date: Sun, 25 Sep 2011 10:47:00 -0000 [thread overview]
Message-ID: <9C4E85B61203CD419BB3A638E5F6833301E5CA98B661@il-ex01.ad.checkpoint.com> (raw)
In-Reply-To: <9C4E85B61203CD419BB3A638E5F6833301E5CA98B64F@il-ex01.ad.checkpoint.com>
Any reference to the below issues would be appreciated. Thanks.
-----Original Message-----
From: Avi Gozlan
Sent: Sunday, September 18, 2011 1:22 PM
To: 'Tom Tromey'; 'gdb-patches@sourceware.org'
Cc: Avi Gozlan; Matan Ben Gur
Subject: Re: [RFC] canonical linespec and multiple breakpoints ...
Hello,
On the basis of your proposal dealing with supporting multiple breakpoints
and the discussion that followed it, I would like to raise some questions.
These issues are highly relevant for our needs (the need was first described
in bug 12313 in the GDB bug database).
Among varying GDB uses, we use GDB to debug a process which loads (using
dlopen) the same exact library multiple times (in fact there are copies of
the library otherwise dlopen returns the same handle for each load). We find
your proposal very useful for us to be able to attach to the process and
debug a specific library. Though, we do have some questions and suggestions.
Pardon technical inaccuracies in GDB terminology.
1) The proposal discusses function breakpoints. Will it also enable
inspecting global and static variables from a specific library?
2) Just to make sure we understand the interaction of the user interface
with "set multiple-symbols": it will be possible to request GDB for a
specific variable/function by a library name without getting it from all
libraries or get a question (ask) each time, right? Otherwise it will be
very inconvenient to inspect multiple variables within a given library.
3) Will the library specific interface know how to handle non-stripped
libraries that are compiled without debug information (no "-g")?
4) We suggest adding an option to enable the GDB backtrace command to
show the library name for each function. In our usage case we have
scenarios in which the libraries interact with each other and a backtrace
showing the library name for each function can enable us understand the
interaction perfectly.
5) Perhaps a little pedantic but what about handling symbols with
different names in libraries with identical name which lie in different
paths?
Thanks,
Avi
next prev parent reply other threads:[~2011-09-25 10:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-18 13:47 Avi Gozlan
2011-09-25 10:47 ` Avi Gozlan [this message]
2011-10-03 16:28 ` Tom Tromey
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=9C4E85B61203CD419BB3A638E5F6833301E5CA98B661@il-ex01.ad.checkpoint.com \
--to=avi@checkpoint.com \
--cc=gdb-patches@sourceware.org \
--cc=matanbg@checkpoint.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