gdb parsing question

gdb parsing question

[Metzger, Markus T]

Hello,

I'm debugging a fail in gdb.base/non-lazy-array-index.exp and I'm wondering why, for parsing '$.f', gdb would lookup 'f' as global symbol [1]?

I would have expected it to lookup the type of '$' and lookup 'f' in its members.

thanks,
markus.

[1]
Temporary breakpoint 1, main () at gdb/testsuite/gdb.base/non-lazy-array-index.c:30
30          return 0;
(gdb) p global_foo
$1 = {
  f = 1,
  array = {1, 2, 3, 4, 5}
}
(gdb)
Thread 1 "gdb" received signal SIGINT, Interrupt.
0x00007ffff764696f in __GI___poll (fds=0x36c4e50, nfds=4, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29          return SYSCALL_CANCEL (poll, fds, nfds, timeout);
(gdb) b svr4_iterate_over_objfiles_in_search_order
Breakpoint 2 at 0xadde6b: file gdb/solib-svr4.c, line 3141.
(gdb) c
Continuing.
p $.f

Thread 1 "gdb" hit Breakpoint 2, svr4_iterate_over_objfiles_in_search_order (gdbarch=0x2a45fa0, cb=..., current_objfile=0x28a4a90)
    at gdb/solib-svr4.c:3141
3141      bool checked_current_objfile = false;
(gdb) bt
#0  svr4_iterate_over_objfiles_in_search_order (gdbarch=0x2a45fa0, cb=..., current_objfile=0x28a4a90)
    at gdb/solib-svr4.c:3141
#1  0x00000000004c58ba in gdbarch_iterate_over_objfiles_in_search_order(gdbarch*, gdb::function_view<bool (objfile*)>, objfile*) (
    gdbarch=0x2a45fa0, cb=..., current_objfile=0x28a4a90) at gdb/gdbarch.c:4937
#2  0x0000000000b3f0da in lookup_global_or_static_symbol (name=0x7fffffffa540 "f", block_index=GLOBAL_BLOCK, objfile=0x28a4a90,
    domain=VAR_DOMAIN) at gdb/symtab.c:2662
#3  0x0000000000b3f239 in lookup_global_symbol (name=0x7fffffffa540 "f", block=0x2a90270, domain=VAR_DOMAIN)
    at gdb/symtab.c:2717
#4  0x0000000000b3eb7e in language_defn::lookup_symbol_nonlocal (this=0x26774a0 <c_language_defn>, name=0x7fffffffa540 "f",
    block=0x2a90270, domain=VAR_DOMAIN) at gdb/symtab.c:2520
#5  0x0000000000b3df97 in lookup_symbol_aux (name=0x7fffffffa540 "f", match_type=symbol_name_match_type::FULL, block=0x2a90270,
    domain=VAR_DOMAIN, language=language_c, is_a_field_of_this=0x0) at gdb/symtab.c:2170
#6  0x0000000000b3d751 in lookup_symbol_in_language (name=0x7fffffffa540 "f", block=0x2a90270, domain=VAR_DOMAIN, lang=language_c,
    is_a_field_of_this=0x0) at gdb/symtab.c:1962
#7  0x0000000000b3d7cc in lookup_symbol (name=0x7fffffffa540 "f", block=0x2a90270, domain=VAR_DOMAIN, is_a_field_of_this=0x0)
    at gdb/symtab.c:1975
#8  0x000000000059250e in classify_name (par_state=0x7fffffffd480, block=0x2a90270, is_quoted_name=false, is_after_structop=true)
    at gdb/c-exp.y:3067
#9  0x0000000000592ba9 in c_yylex () at gdb/c-exp.y:3278
#10 0x000000000058a10e in c_yyparse () at /users/mmetzger/team/gdb/build/labpc2407/gdb/c-exp.c.tmp:2037
#11 0x0000000000593647 in c_parse (par_state=0x7fffffffd480) at gdb/c-exp.y:3444
#12 0x000000000081e75e in language_defn::parser (this=0x26774a0 <c_language_defn>, ps=0x7fffffffd480)
    at gdb/language.c:623
#13 0x000000000093da0e in parse_exp_in_context (stringptr=0x7fffffffd590, pc=0, block=0x0, comma=0, void_context_p=false,
    tracker=0x7fffffffd500, completer=0x0) at gdb/parse.c:515
#14 0x000000000093dbea in parse_expression (string=0x3349152 "$.f", tracker=0x0, void_context_p=false)
    at gdb/parse.c:551
#15 0x000000000096ff06 in process_print_command_args (args=0x3349152 "$.f", print_opts=0x7fffffffd6a0, voidprint=true)
    at gdb/printcmd.c:1306
#16 0x000000000096ffa2 in print_command_1 (args=0x3349152 "$.f", voidprint=1) at gdb/printcmd.c:1320
#17 0x00000000009703e6 in print_command (exp=0x3349152 "$.f", from_tty=1) at gdb/printcmd.c:1453
#18 0x00000000005c6cba in do_simple_func (args=0x3349152 "$.f", from_tty=1, c=0x28b6610)
    at gdb/cli/cli-decode.c:95
#19 0x00000000005cb84c in cmd_func (cmd=0x28b6610, args=0x3349152 "$.f", from_tty=1)
    at gdb/cli/cli-decode.c:2514
#20 0x0000000000b96c6d in execute_command (p=0x3349154 "f", from_tty=1) at gdb/top.c:699
#21 0x0000000000744dc5 in command_handler (command=0x3349150 "p $.f") at gdb/event-top.c:598
#22 0x0000000000745267 in command_line_handler (rl=...) at gdb/event-top.c:842
#23 0x0000000000bc0a4a in tui_command_line_handler (rl=...) at gdb/tui/tui-interp.c:278
#24 0x00000000007445ca in gdb_rl_callback_handler (rl=0x36c4a70 "p $.f") at gdb/event-top.c:230
#25 0x0000000000cad8a0 in rl_callback_read_char () at readline/readline/callback.c:290
#26 0x000000000074442e in gdb_rl_callback_read_char_wrapper_noexcept () at gdb/event-top.c:188
#27 0x00000000007444cf in gdb_rl_callback_read_char_wrapper (client_data=0x27120d0) at gdb/event-top.c:205
#28 0x0000000000744c18 in stdin_event_handler (error=0, client_data=0x27120d0) at gdb/event-top.c:525
#29 0x000000000135f224 in handle_file_event (file_ptr=0x2b3cf40, ready_mask=1) at gdbsupport/event-loop.cc:549
#30 0x000000000135f7c3 in gdb_wait_for_event (block=1) at gdbsupport/event-loop.cc:670
#31 0x000000000135e771 in gdb_do_one_event () at gdbsupport/event-loop.cc:235
#32 0x00000000008834fc in start_event_loop () at gdb/main.c:413
#33 0x000000000088361b in captured_command_loop () at gdb/main.c:473
#34 0x0000000000884e38 in captured_main (data=0x7fffffffdd80) at gdb/main.c:1335
#35 0x0000000000884e9e in gdb_main (args=0x7fffffffdd80) at gdb/main.c:1350
#36 0x0000000000412f9d in main (argc=8, argv=0x7fffffffdeb8) at gdb/gdb.c:32
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: gdb parsing question

[Tom Tromey]

> I'm debugging a fail in gdb.base/non-lazy-array-index.exp and I'm
> wondering why, for parsing '$.f', gdb would lookup 'f' as global
> symbol [1]?

> I would have expected it to lookup the type of '$' and lookup 'f' in its members.

I am not really sure, but the lexer in c-exp.y doesn't really know a
whole lot.  It often has no idea of the context, so when classifying a
name it may do some lookup.  That is, there may not be a real reason.

Whether or not the result of this lookup is then used in the parser is a
different question -- for example the field_name production seems to
just use the underlying 'stoken', which is just the text.

Tom

RE: gdb parsing question

[Metzger, Markus T]

Thanks, Tom,

>> I'm debugging a fail in gdb.base/non-lazy-array-index.exp and I'm
>> wondering why, for parsing '$.f', gdb would lookup 'f' as global
>> symbol [1]?
>
>> I would have expected it to lookup the type of '$' and lookup 'f' in its members.
>
>I am not really sure, but the lexer in c-exp.y doesn't really know a
>whole lot.  It often has no idea of the context, so when classifying a
>name it may do some lookup.  That is, there may not be a real reason.
>
>Whether or not the result of this lookup is then used in the parser is a
>different question -- for example the field_name production seems to
>just use the underlying 'stoken', which is just the text.

The test checks that we're not doing any xfer when evaluating from the
history.  When adding linker namespaces, however, we need to read the
debug base as part of svr4_iterate_over_objfiles_in_search_order().  This
may require xfers.

GDB used to cache that but all places have been changed to re-read it
every time to handle relocating it as comments suggest.

I changed the test to check for auxv accesses and treat this as XFAIL.

regards,
markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928