This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 7/9] compile: New 'compile print'
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Phil Muldoon <pmuldoon at redhat dot com>
- Date: Wed, 06 May 2015 15:10:59 +0100
- Subject: Re: [PATCH v3 7/9] compile: New 'compile print'
- Authentication-results: sourceware.org; auth=none
- References: <20150411194322 dot 29128 dot 52477 dot stgit at host1 dot jankratochvil dot net> <20150411194418 dot 29128 dot 3411 dot stgit at host1 dot jankratochvil dot net> <5540FD9E dot 1020005 at redhat dot com> <20150503140557 dot GB18394 at host1 dot jankratochvil dot net> <5549EB49 dot 2050206 at redhat dot com> <20150506122301 dot GA20986 at host1 dot jankratochvil dot net>
On 05/06/2015 01:23 PM, Jan Kratochvil wrote:
> On Wed, 06 May 2015 12:22:01 +0200, Pedro Alves wrote:
>> On 05/03/2015 03:05 PM, Jan Kratochvil wrote:
>>> Function returns NULL only for COMPILE_I_PRINT_ADDRESS_SCOPE when
>>> COMPILE_I_PRINT_VALUE_SCOPE should have been used instead.
>>
>> What does "should have been used instead" mean? Is that a bug in the
>> caller?
>
> Currently GDB has to decide whether it should compile with GCC
> memcpy (buffer, &variable, ...)
> or
> memcpy (buffer, variable, ...)
> depending on whether 'variable' is scalar (first) or an array (second).
>
> Currently GDB can figure it out only from DWARF, after compiling it first.
>
> This is all a hack how to get it working for live targets without implementing
> the compiler IR (intermediate representation) interpreter in GDB (making
> 'compile' commands compatible with core files). So far AFAIK C++ live
> functionality has been a top priority, not the IR interpreter. This
> COMPILE_I_PRINT_ADDRESS_SCOPE-or-COMPILE_I_PRINT_VALUE_SCOPE conditional would
> be some simple runtime conditional in the IR interpreter instead.
>
> If an implementation on top of IR interpreter is required for these patches
> then this whole patch series should be dropped and we need to start to work on
> the IR interpreter instead.
No, IR interpreter is certainly not a requirement.
But I think the comment that explains the current implementation should
be clear. As is, it's just that I still don't understand what you mean by:
> Function returns NULL only for COMPILE_I_PRINT_ADDRESS_SCOPE when
> COMPILE_I_PRINT_VALUE_SCOPE should have been used instead.
because reading this one wonders: "OK, if COMPILE_I_PRINT_VALUE_SCOPE should
have been used, why wasn't it used then? Is that a bug in the caller?"
Thanks,
Pedro Alves