This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 9/9] compile: compile printf: gdbserver support
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: gdb-patches at sourceware dot org
- Cc: Phil Muldoon <pmuldoon at redhat dot com>
- Date: Sun, 26 Apr 2015 11:33:18 +0200
- Subject: Re: [PATCH v3 9/9] compile: compile printf: gdbserver support
- Authentication-results: sourceware.org; auth=none
- References: <20150411194322 dot 29128 dot 52477 dot stgit at host1 dot jankratochvil dot net> <20150411194437 dot 29128 dot 58569 dot stgit at host1 dot jankratochvil dot net>
On Sat, 11 Apr 2015 21:44:37 +0200, Jan Kratochvil wrote:
> former patch injects plain:
> printf (...);
> This patch injects gdbserver-compatible:
> f = open_memstream (&s, ...);
> fprintf (f, ...);
> fclose (f);
> return s;
I have realized this print+printf patchset introduces calling inferior
implicit malloc() + explicit free() (by free_inferior_memory) which the
original 'compile code' series avoided (using gdbarch_infcall_mmap() instead).
The goal was not to crash the inferior futher with print commands when
analyzing corrupted inferior memory lists.
I somehow expected that printf()/fprintf() are so heavyweight they will call
malloc() on their own so this mmap goal is no longer achievable for printf.
But I have found now glibc in most real world cases uses just alloca().
The problem is even calling fmemopen() instead of open_memstream() still
implicitly calls malloc() - for fmemopen_cookie_t and for FILE.
The only idea I have is to redirect by a breakpoint glibc's implicit calls to
malloc() into GDB's allocator by inferior mmap. But that seems a bit ugly.
So currently keeping it as a known bug.
Jan