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: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Phil Muldoon <pmuldoon at redhat dot com>
- Date: Sun, 3 May 2015 16:06:12 +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> <20150426093318 dot GA6765 at host1 dot jankratochvil dot net> <5540FEA3 dot 7050406 at redhat dot com>
On Wed, 29 Apr 2015 17:54:11 +0200, Pedro Alves wrote:
> On 04/26/2015 10:33 AM, Jan Kratochvil wrote:
> > 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.
>
> Using mmap along with snprintf would be safer, but given that snprintf is
> not async-signal-safe in general either, it's fine with me to leave this
> as you have it.
OK, snprintf into mmap()ped buffer looks easier. While snprintf is not
async-signal-safe in general IMO it is async-signal-safe for most format
strings given in almost always uses alloca() instead of malloc().
Or do you realize other problems it may have?
Still I am sure fine to check it in as is if it is approved this way.
> I think the manual should say that the command internally may call
> functions that are not async-signal-safe though.
Done.
Thanks,
Jan