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

[Pedro Alves <palves at redhat dot com>]

On 06/29/2017 12:05 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> 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.)
> 
> Yes, GDB target description uses VEC, so I chose VEC for GDBserver
> target description too.

OK.

> 
>>
>> [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.
> 
> Such usage is documented, at least,
> https://sourceware.org/gdb/onlinedocs/gdb/Server.html

Yeah.  We also call "malloc" in the inferior (value_allocate_space_in_inferior)
for coercing arrays, etc. to the inferior ('print "hello"', etc.) which
suffers from the same problem.  I'm often surprised how we
don't hear more bug reports about that.

> 
>> 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).]
> 
> Do you suggest that we need to use std::vector plus a customized
> allocator which uses mmap?

No, not now, at least.  At first I thought that using VEC instead of
static arrays would be the introducing the problem of using
malloc in the initialization path.  Then while writing a
review in that direction I looked at the code and
realized/remembered that it's not really a new problem.
But I chose to dump my thoughts on how that might
be fixable in the future as a parenthesis.  I don't mean
to go fix that now.

Thanks,
Pedro Alves