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 11:22:01 +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>
On 05/03/2015 03:05 PM, Jan Kratochvil wrote:
> On Wed, 29 Apr 2015 17:49:50 +0200, Pedro Alves wrote:
>> On 04/11/2015 08:44 PM, Jan Kratochvil wrote:
>>
>>> + case COMPILE_I_PRINT_ADDRESS_SCOPE:
>>> + case COMPILE_I_PRINT_VALUE_SCOPE:
>>> + fputs_unfiltered ("#include <string.h>\n"
>>
>> OOC, why do we need the include?
>
> Added:
> + /* <string.h> is needed for a memcpy call below. */
>
Thanks.
>>>
>>> +/* Fetch the type of COMPILE_I_EXPR_PTR_TYPE and COMPILE_I_EXPR_VAL
>>> + symbols in OBJFILE so we can calculate how much memory to allocate
>>> + for the out parameter. This avoids needing a malloc in the generated
>>> + code. Throw an error if anything fails.
>>> + Set *OUT_VALUE_TAKE_ADDRESSP depending whether inferior code should
>>> + copy COMPILE_I_EXPR_VAL or its address - this depends on __auto_type
>>> + array-to-pointer type conversion of COMPILE_I_EXPR_VAL, as detected
>>> + by COMPILE_I_EXPR_PTR_TYPE preserving the array type. */
>>
>> This comment seems a bit stale. At least, I don't see an
>> OUT_VALUE_TAKE_ADDRESSP parameter.
>
> OK, yes, updated.
>
> 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?
> This depends on __auto_type array-to-pointer type conversion of
> COMPILE_I_EXPR_VAL, as detected by COMPILE_I_EXPR_PTR_TYPE preserving
> the array type. */
Thanks,
Pedro Alves