Re: [PATCH] Make ada_decode not use a static buffer

["Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>]

On Fri, Sep 20, 2019 at 3:58 PM Tom Tromey <tom@tromey.com> wrote:
>
> >>>>> "Christian" == Christian Biesinger via gdb-patches <gdb-patches@sourceware.org> writes:
>
> Christian> This makes it safer to use in general, and also allows using it on a
> Christian> background thread in the future.
>
> Christian> Inspired by tromey's patch at:
> Christian> https://github.com/tromey/gdb/commit/1226cbdfa436297a5dec054d94592c45891afa93
> Christian> (however, implemented in a different way)
>
> Sorry about the long delay on this.
>
> Christian>  /* If ENCODED follows the GNAT entity encoding conventions, then return
> Christian>     the decoded form of ENCODED.  Otherwise, return "<%s>" where "%s" is
> Christian> -   replaced by ENCODED.
> Christian> +   replaced by ENCODED.  */
>
> Christian> -   The resulting string is valid until the next call of ada_decode.
> Christian> -   If the string is unchanged by decoding, the original string pointer
> Christian> -   is returned.  */
>
> I wonder if the "unchanged" part is a useful optimization.
> If so, then maybe my approach is preferred, though perhaps with
> a new type -- something Pedro pointed out in review.
>
> Something else he mentioned is that he came across a test case where
> this function had a performance impact.  To test this, next week I'll
> try out your patch on a large Ada program we have here to measure the
> impact.  Hopefully it will show nothing, and we can just move forward.

Thank you! For reference, this is Pedro's email where he pointed that out:
https://sourceware.org/ml/gdb-patches/2019-05/msg00673.html

It sounds like one concern was over sniffing the minsym language. It
seems like that shouldn't need allocations at all.

BTW, another option would be to have a thread-local std::string in the
function and reuse that. (or an std::string in a class like Pedro
described)

Christian