This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How to implement '@' GDB-like operator for libcc1
- From: Manuel López-Ibáñez <lopezibanez at gmail dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Phil Muldoon <pmuldoon at redhat dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Mon, 16 Mar 2015 10:33:26 +0100
- Subject: Re: How to implement '@' GDB-like operator for libcc1
- Authentication-results: sourceware.org; auth=none
- References: <CAESRpQAtr_YWO2VM3XuZoxS3Tk0v=nxV0g1HvOTn=RbFfez-WA at mail dot gmail dot com> <CAESRpQBeTmybaoasUH1K-hH5RPa2AY4gnKqmyvuKzyeBLMb5TA at mail dot gmail dot com> <20150316083236 dot GA25027 at host1 dot jankratochvil dot net>
On 16 March 2015 at 09:32, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> On Mon, 16 Mar 2015 04:22:35 +0100, Manuel López-Ibáñez wrote:
>> Thus, the question is what info GDB needs from GCC to be able to print
>> the contents of the array.
>
> Variable with an array type in DWARF.
How does it work then for pointers?
int *p = malloc(...);
(gdb) p *p@3
should also work.
>> And it probably just needs the type of whatever is to the left of @ and the
>> value of whatever is to the right of @, no?
>
> There are two ways how to fix that. As '@' makes sense only at the outermost
> operator of an expression GDB could strip it and not to pass it to GCC at all.
> But then there would be unhandled corner cases like parentheses:
> (gdb) print (*a@3)
Would it be so difficult to strip parentheses? I honestly think it
might be easier than adding special handling for @ to the C parser.
I think there are more options: GDB could also convert @ to something
that GCC can understand, like a function call, or a cast to a
gdb-defined type, and that will trigger the generation of the desired
DWARF.
> Then there also is an option to hook GDB somewhere into the expression parser
> of GCC. GDB currently implements 'compile print' just by compiling a special
> generated .c file into .o and running .o + parsing the .o's DWARF to find the
> proper type, see below.
There is also the option that GDB calls directly into the parser and
when it detects an expression containing @ that GCC cannot parse, uses
GCC to split the left and right operand around @. This would need some
tweaking of the parser (override the error function, save intermediate
parsing results), but it goes in the right direction: Making the
parser more generally re-usable. I admit it is harder than the above.
> Depending on the DWARF types of __gdb_expr_val and __gdb_expr_ptr_type GDB will
> pass the boolean flag '__gdb_expr_take_address' to handle arrays correctly, one
> can see it for:
Would it be possible for GDB to generate code such that this trick is
generated for @? Perhaps by creating a dummy array variable, then
applying typeof(dummy) like you do below.
> (gdb) l
> 1 int main(void) {
> 2 int i=0; __auto_type i_val=i; typeof(i) *i_ptr_type;
> 3 int a[]={1,2,3}; __auto_type a_val=a; typeof(a) *a_ptr_type;
> 4 return 0; }
> (gdb) ptype i_val
> type = int
> (gdb) ptype i_ptr_type
> type = int *
> -> i_ptr_type == i_val * => __gdb_expr_take_address=true
> (gdb) ptype a_val
> type = int *
> (gdb) ptype a_ptr_type
> type = int (*)[3]
> -> i_ptr_type == (&*i_val)* && i_val is array => __gdb_expr_take_address=false
> Implemented by:
> https://github.com/tromey/gdb/commit/6ec13bc75ebbaa3b5fab8ecda8518af56cc5e2e8
Cheers,
Manuel.