Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Andrew Burgess <aburgess@broadcom.com>, gcc-patches@gcc.gnu.org
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] demangler, only access valid fields for DEMANGLE_COMPONENT_FIXED_TYPE.
Date: Wed, 28 May 2014 22:56:00 -0000	[thread overview]
Message-ID: <538669AD.8020502@redhat.com> (raw)
In-Reply-To: <1401309510-10507-1-git-send-email-aburgess@broadcom.com>

On 05/28/2014 09:38 PM, Andrew Burgess wrote:
> In two places when a struct demangle_component is of type
> DEMANGLE_COMPONENT_FIXED_TYPE we fall back to accessing the default
> s_binary member of the union rather than the s_fixed member.  This is
> incorrect and can cause the demangler to crash.
> 
> In d_dump I've changed the code to only access the s_fixed member of the
> union, and also added printing of the remaining parts of the s_fixed
> struct, this felt like the most useful thing to do.
> 
> I've added a new test, this causes a SIGSEGV for me before the patch, and
> is fine afterwords, however, this undefined, so might not cause a crash on
> all platforms.

Hi Andrew,

As you know, I'm not a demangler maintainer, but in any case, I took a look
and this looks good to me.

> diff --git a/libiberty/testsuite/demangle-expected b/libiberty/testsuite/demangle-expected
> index 453f9a3..0e2bb12 100644
> --- a/libiberty/testsuite/demangle-expected
> +++ b/libiberty/testsuite/demangle-expected
> @@ -4343,3 +4343,9 @@ cereal::detail::InputBindingMap<cereal::JSONInputArchive>::Serializers cereal::p
>  --format=gnu-v3
>  _ZNSt9_Any_data9_M_accessIPZ4postISt8functionIFvvEEEvOT_EUlvE_EERS5_v
>  void post<std::function<void ()> >(std::function<void ()>&&)::{lambda()#1}*& std::_Any_data::_M_access<void post<std::function<void ()> >(void post<std::function<void ()> >(std::function<void ()>&&)::{lambda()#1}*&&)::{lambda()#1}*>()
> +# The following input symbol was found during random, it caused a fault

Could you add a single empty # above, to separate the tests?
I find that that makes it much easier to follow the file.
I have no idea why we can't have/handle real empty lines though.

> +# The following input symbol was found during random, it caused a fault

"during random testing?"

> +# within the demangler, it's not a symbol we'd expect in the real world.

Why not?

> +--format=auto --no-params
> +_Z3xxxDFyuVb
> +xxx(unsigned long long _Fract, bool volatile)
> +xxx
-- 
Pedro Alves


  reply	other threads:[~2014-05-28 22:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-28 20:38 Andrew Burgess
2014-05-28 22:56 ` Pedro Alves [this message]
2014-05-28 23:57   ` Andrew Burgess

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=538669AD.8020502@redhat.com \
    --to=palves@redhat.com \
    --cc=aburgess@broadcom.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdb-patches@sourceware.org \
    /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