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

[Yao Qi <qiyaoltc at gmail dot com>]

Pedro Alves <palves@redhat.com> writes:

>>> [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 can understand IPA calls malloc may cause deadlock in the inferior, if
the inferior has already acquired the lock for malloc.  Think it a bit
more during lunch, I don't understand how it is related to
non-async-signal-safe functions?  Is it that main program executed some
non-async-signal-safe function, signal arrives, goes to signal handler,
hits a breakpoint or fast tracepoint here.  Then, the
non-async-signal-safe functions may be executed again either by gdb
inferior call or IPA.  If this is the problem, ...

>> 
>>> 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.

... then, we can't use std::vector either, because it may throw
exception, or we somehow need to guarantee that the std::vector we used
doesn't throw exception.

-- 
Yao (齐尧)