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: 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: Wed, 6 May 2015 21:18:16 +0200
- 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>
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. */
Plus at:
enum compile_i_scope_types
name already specifies its address. See get_out_value_type. */
COMPILE_I_PRINT_ADDRESS_SCOPE,
COMPILE_I_PRINT_VALUE_SCOPE,
Jan