This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug c++/20091] New: Breakpoints in @plt routines are almost never useful
- From: "richard at theshapirogroup dot org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Fri, 13 May 2016 15:58:03 +0000
- Subject: [Bug c++/20091] New: Breakpoints in @plt routines are almost never useful
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=20091
Bug ID: 20091
Summary: Breakpoints in @plt routines are almost never useful
Product: gdb
Version: 7.11.1
Status: NEW
Severity: normal
Priority: P2
Component: c++
Assignee: unassigned at sourceware dot org
Reporter: richard at theshapirogroup dot org
Target Milestone: ---
I'm debugging in a large system with many shared libraries. If I set a
breakpoint in zap::thing, I get a breakpoint in zap::thing@plt and zap::thing.
The former is almost never interesting (at least to me as an application
developer; maybe as a compiler writer I would care more). So, I would like a
way to turn this off.
I will observe that there is code in bfd/bfd.c to cause c++ demangling to match
zap::thing@plt
/* Strip off @plt and suchlike too. */
alloc = NULL;
suf = strchr (name, '@');
if (suf != NULL)
{
alloc = (char *) bfd_malloc (suf - name + 1);
if (alloc == NULL)
return NULL;
memcpy (alloc, name, suf - name);
alloc[suf - name] = '\0';
name = alloc;
}
setting suf to NULL is sufficient to suppress the spurious breakpoints. It
would be nice if this could be controlled with an option.
--
You are receiving this mail because:
You are on the CC list for the bug.