This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/20091] New: Breakpoints in @plt routines are almost never useful


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]