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: Fri, 15 May 2015 17:35:41 +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> <554A20F3 dot 1010404 at redhat dot com> <20150506191816 dot GA12839 at host1 dot jankratochvil dot net>
On 05/06/2015 08:18 PM, Jan Kratochvil wrote:
> On Wed, 06 May 2015 16:10:59 +0200, Pedro Alves wrote:
>> On 05/06/2015 01:23 PM, Jan Kratochvil wrote:
>>> 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.
>
> IIUC in this case the hack has an acceptable scale (contrary to that printf).
>
>
>> 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?"
>
> I have put there now:
> GDB first tries to compile the code with COMPILE_I_PRINT_ADDRESS_SCOPE.
> If it finds user tries to print an array type this function returns
> NULL. Caller will then regenerate the code with
> COMPILE_I_PRINT_VALUE_SCOPE, recompiles it again and finally runs it.
> This is because __auto_type array-to-pointer type conversion of
> COMPILE_I_EXPR_VAL which gets detected by COMPILE_I_EXPR_PTR_TYPE
> preserving the array type. */
>
Aaaaaaaaah. I see now. Thanks, that's _so_ much better.
Yes, this hack is fine with me. We have bigger fish to fry.
Let me go take a look at the new series you posted.
--
Pedro Alves