Re: [PATCH v3 7/9] compile: New 'compile print'

[Pedro Alves <palves@redhat.com>]

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