Re: [patch] compile: Fix MinGW build [Re: [mingw rfc] Add mkdtemp to gdb/gnulib/]

[Pedro Alves <palves at redhat dot com>]

On 12/17/2014 07:31 PM, Eli Zaretskii wrote:
>> Date: Wed, 17 Dec 2014 20:17:55 +0100
>> From: Jan Kratochvil <jan.kratochvil@redhat.com>
>> Cc: brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org,
>>         ktietz@redhat.com
>>
>>>> linux-tdep.c:
>>>>   set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap);
>>>
>>> Why is mmap needed here?
>>
>> The project obviously needs something like:
>> 	(gdb) call dlopen("just compile piece of code.so");
>>
>> But as dlopen() is intrusive to the inferior Tom decided it is better to do
>> much less intrusive
>> 	(gdb) print mmap(...)
>>
>> instead and reimplement what inferior dlopen() does
>> in gdb/compile/compile-object-load.c - which is being done.
> 
> Why is dlopen "intrusive"?

Pasting here what I said recently on a glibc thread, re. reasons
for not using dlopen for this.

Off the top of my head, I'm sure there are more:

 - The user might want to evaluate an expression while the program itself
   has just called dlopen and is now stopped inside it.  This pesky dlopen
   recursion thing.    It's best if GDB only calls async-signal
   safe functions behind the scenes, if possible.  Of course if the
   injected expression involves calls to async-signal unsafe code that breaks
   the inferior, the user gets what she asked for.

 - The program might have not been linked with -ldl.

 - I suspect there may be issues with messing with symbol resolution
   and self library walks in the inferior too.  Not sure if RTLD_LOCAL is
   enough.  dlmopen might be a better fit, but hmm, that isn't very
   well supported in GDB/glibc.

 - A lower level mechanism has much better chances of working on
   more targets and runtimes-of-languages-other-than-C with minimal
   changes.

> ISTM that using the Windows equivalent of dlopen is exactly the right thing here.

That may well be, though I think that it's better if "info shared"
doesn't show the modules injected into the inferior, which using LoadLibrary
(Windows's dlopen) would give you.


Note that set_gdbarch_infcall_mmap doesn't need to implement the
whole feature set of mmap.  We only need to be able to carve out a
piece of memory.  Should map trivially to VirtualAlloc.


I expect that we'll end up using this same gdbarch hook to allocate
memory in the inferior when we need to coerce variables to the inferior.
We currently call "malloc" for that, which isn't ideal in the sense
that the inferior can well be already inside malloc when we do that,
leading do deadlock or corruption.

Thanks,
Pedro Alves