Re: [PATCH 11/25] Use VEC for target_desc.reg_defs

[Pedro Alves <palves at redhat dot com>]

On 06/12/2017 09:41 AM, Yao Qi wrote:
> Nowadays, target_desc.reg_defs is a pointer points to a pre-generated
> array, which is not flexible.  This patch changes it from an array
> to a VEC so that GDBserver can create target descriptions dynamically
> later.  Instead of using pre-generated array, the -generated.c calls
> VEC_safe_push to add each register to vector.
> 
> Since target_desc.reg_defs is used in IPA, we need to build common/vec.c
> for IPA too.

Can you say more about the choice of VEC?  It feels
like new uses should come with a rationale for why it'd
be preferred over std::vector.

I'm guessing that it's because the gdb side uses VEC too?
Or is it something else?  (I can guess other reasons, but
the point is that we shouldn't have to guess.)

[Note that the IPA avoids calling the inferior's malloc during
normal operation, to avoid deadlocking the inferior.
This is initialization code, so it's not covered by the exact
same level of concern, even though one of the original goals was
to also be able to inject the IPA into a running inferior (e.g., by
calling dlopen via gdb).  That does work (or at least used to),
but it's a little unsafe because the IPA initialization code
already calls malloc and other non-async-signal-safe functions.
I guess std::vector would make it possible to use a custom
allocator in the IPA that would allocate memory with mmap
directly (or we'd make the IPA's xmalloc allocate with mmap,
and then the allocator would use xmalloc).]

Thanks,
Pedro Alves