| Message ID | 1489356354-27648-1-git-send-email-mark@klomp.org |
|---|---|
| State | New |
| Headers | show |
On Sun, Mar 12, 2017 at 3:05 PM, Mark Wielaard <mark@klomp.org> wrote: > While integrating the d_printing recursion guard change into gdb I > noticed we forgot to initialize the demangle_component d_printing > field in cplus_demangle_fill_{name,extended_operator,ctor,dtor}. > As is done in cplus_demangle_fill_{component,builtin_type,operator}. > It happened to work because in gcc all demangle_components were > allocated through d_make_empty. But gdb has its own allocation > mechanism (as might other users). > > libiberty/ChangeLog: > > * cp-demangle.c (cplus_demangle_fill_name): Initialize > demangle_component d_printing. > (cplus_demangle_fill_extended_operator): Likewise. > (cplus_demangle_fill_ctor): Likewise. > (cplus_demangle_fill_dtor): Likewise. This is OK. Thanks. Ian
On 2017.03.12 at 23:05 +0100, Mark Wielaard wrote: > While integrating the d_printing recursion guard change into gdb I > noticed we forgot to initialize the demangle_component d_printing > field in cplus_demangle_fill_{name,extended_operator,ctor,dtor}. > As is done in cplus_demangle_fill_{component,builtin_type,operator}. > It happened to work because in gcc all demangle_components were > allocated through d_make_empty. But gdb has its own allocation > mechanism (as might other users). Nick has synced the binutils-gdb repro with gcc's. I think you should commit your fix as obvious. And it would be nice if Nick could sync again, after your patch went in.
diff --git a/libiberty/ChangeLog b/libiberty/ChangeLog index e93e327..b513fce 100644 --- a/libiberty/ChangeLog +++ b/libiberty/ChangeLog @@ -1,3 +1,11 @@ +2017-03-12 Mark Wielaard <mark@klomp.org> + + * cp-demangle.c (cplus_demangle_fill_name): Initialize + demangle_component d_printing. + (cplus_demangle_fill_extended_operator): Likewise. + (cplus_demangle_fill_ctor): Likewise. + (cplus_demangle_fill_dtor): Likewise. + 2017-03-08 Mark Wielaard <mark@klomp.org> PR demangler/70909 diff --git a/libiberty/cp-demangle.c b/libiberty/cp-demangle.c index 341a418..04832ff 100644 --- a/libiberty/cp-demangle.c +++ b/libiberty/cp-demangle.c @@ -854,6 +854,7 @@ cplus_demangle_fill_name (struct demangle_component *p, const char *s, int len) { if (p == NULL || s == NULL || len == 0) return 0; + p->d_printing = 0; p->type = DEMANGLE_COMPONENT_NAME; p->u.s_name.s = s; p->u.s_name.len = len; @@ -869,6 +870,7 @@ cplus_demangle_fill_extended_operator (struct demangle_component *p, int args, { if (p == NULL || args < 0 || name == NULL) return 0; + p->d_printing = 0; p->type = DEMANGLE_COMPONENT_EXTENDED_OPERATOR; p->u.s_extended_operator.args = args; p->u.s_extended_operator.name = name; @@ -888,6 +890,7 @@ cplus_demangle_fill_ctor (struct demangle_component *p, || (int) kind < gnu_v3_complete_object_ctor || (int) kind > gnu_v3_object_ctor_group) return 0; + p->d_printing = 0; p->type = DEMANGLE_COMPONENT_CTOR; p->u.s_ctor.kind = kind; p->u.s_ctor.name = name; @@ -907,6 +910,7 @@ cplus_demangle_fill_dtor (struct demangle_component *p, || (int) kind < gnu_v3_deleting_dtor || (int) kind > gnu_v3_object_dtor_group) return 0; + p->d_printing = 0; p->type = DEMANGLE_COMPONENT_DTOR; p->u.s_dtor.kind = kind; p->u.s_dtor.name = name;
While integrating the d_printing recursion guard change into gdb I noticed we forgot to initialize the demangle_component d_printing field in cplus_demangle_fill_{name,extended_operator,ctor,dtor}. As is done in cplus_demangle_fill_{component,builtin_type,operator}. It happened to work because in gcc all demangle_components were allocated through d_make_empty. But gdb has its own allocation mechanism (as might other users). libiberty/ChangeLog: * cp-demangle.c (cplus_demangle_fill_name): Initialize demangle_component d_printing. (cplus_demangle_fill_extended_operator): Likewise. (cplus_demangle_fill_ctor): Likewise. (cplus_demangle_fill_dtor): Likewise. --- libiberty/ChangeLog | 8 ++++++++ libiberty/cp-demangle.c | 4 ++++ 2 files changed, 12 insertions(+)