[Bug breakpoints/15826] New: Slow symbol lookups during conditional breakpoints

[Bug breakpoints/15826] New: Slow symbol lookups during conditional breakpoints

[mjw at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15826

            Bug ID: 15826
           Summary: Slow symbol lookups during conditional breakpoints
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: mjw at redhat dot com

If I have a breakpoint with a condition either a "normal" breakpoint or a
-probe breakpoint it looks like gdb is doing symbol table lookups every time a
condition is being checked. This makes using conditional breakpoints extremely
slow.

Two examples from debugging LibreOffice (some background context:
http://lists.freedesktop.org/archives/libreoffice/2013-August/055022.html)

With a "normal" breakpoint with expression:

(gdb) info b
Num     Type           Disp Enb Address            What
4       breakpoint     keep y   <MULTIPLE>         
    stop only if (*ppThis)->refCount == 1 && (*ppThis)->length == 99
    breakpoint already hit 5 times
4.1                         y     0x00002aaaaaadc866 in
rtl_string_newConcat(rtl_String**, rtl_String*, rtl_String*) 
                                                   at
/usr/local/src/libreoffice/sal/rtl/strtmpl.cxx:1410
4.2                         y     0x00002aaaaaae0b2f in
rtl_uString_newConcat(rtl_uString**, rtl_uString*, rtl_uString*) 
                                                   at
/usr/local/src/libreoffice/sal/rtl/strtmpl.cxx:1410

perf top will show:

  38.48%  gdb                             [.] lookup_symbol_aux_psymtabs
  18.29%  gdb                             [.] lookup_partial_symbol.isra.3
   8.39%  gdb                             [.] symbol_natural_name
   8.21%  gdb                             [.] lookup_symbol_aux_objfile
   6.67%  gdb                             [.] strcmp_iw_ordered

Attaching another gdb will show the following backtrace:

#0  0x0000000000648e62 in strcmp_iw_ordered (string1=<optimized out>, 
    string2=<optimized out>, string2@entry=0x175aa360 "bool")
    at ../../gdb/utils.c:2715
#1  0x000000000055b7d6 in lookup_partial_symbol (pst=pst@entry=0xb85d0d8, 
    name=name@entry=0x746ed9 "bool", global=global@entry=1, 
    domain=domain@entry=VAR_DOMAIN, objfile=0xca7c840, objfile=0xca7c840)
    at ../../gdb/psymtab.c:696
#2  0x000000000055c7ce in lookup_symbol_aux_psymtabs (objfile=0xca7c840, 
    block_index=0, name=0x746ed9 "bool", domain=VAR_DOMAIN)
    at ../../gdb/psymtab.c:501
#3  0x0000000000556bfd in lookup_symbol_aux_quick (
    objfile=objfile@entry=0xca7c840, kind=kind@entry=0, name=0x746ed9 "bool", 
    domain=VAR_DOMAIN) at ../../gdb/symtab.c:1630
#4  0x0000000000556dc0 in lookup_symbol_global_iterator_cb (objfile=0xca7c840, 
    cb_data=0x7fffef98cc70) at ../../gdb/symtab.c:1759
#5  0x00000000005bcd11 in default_iterate_over_objfiles_in_search_order (
    gdbarch=<optimized out>, cb=0x556d70 <lookup_symbol_global_iterator_cb>, 
    cb_data=0x7fffef98cc70, current_objfile=<optimized out>)
    at ../../gdb/objfiles.c:1480
#6  0x0000000000556825 in lookup_symbol_global (
    name=name@entry=0x746ed9 "bool", block=block@entry=0x0, 
    domain=domain@entry=VAR_DOMAIN) at ../../gdb/symtab.c:1790
#7  0x0000000000657496 in lookup_symbol_file (name=name@entry=0x746ed9 "bool", 
    block=block@entry=0x0, domain=domain@entry=VAR_DOMAIN, 
    anonymous_namespace=anonymous_namespace@entry=0, search=1)
    at ../../gdb/cp-namespace.c:632
#8  0x0000000000657670 in cp_lookup_symbol_in_namespace (
    namespace=namespace@entry=0x725cab "", name=name@entry=0x746ed9 "bool", 
    block=block@entry=0x0, domain=domain@entry=VAR_DOMAIN, 
    search=search@entry=1) at ../../gdb/cp-namespace.c:255
#9  0x0000000000657bd1 in cp_lookup_symbol_namespace (scope=0x725cab "", 
    name=0x746ed9 "bool", block=0x0, domain=VAR_DOMAIN)
    at ../../gdb/cp-namespace.c:526
#10 0x0000000000556f4f in lookup_symbol_aux (is_a_field_of_this=0x0, 
    language=<optimized out>, domain=VAR_DOMAIN, block=0x0, 
    name=0x746ed9 "bool") at ../../gdb/symtab.c:1365
#11 lookup_symbol_in_language (name=<optimized out>, block=block@entry=0x0, 
    domain=domain@entry=VAR_DOMAIN, lang=<optimized out>, 
    is_a_field_of_this=is_a_field_of_this@entry=0x0) at ../../gdb/symtab.c:1211
#12 0x0000000000557022 in lookup_symbol (name=<optimized out>, 
    block=block@entry=0x0, domain=domain@entry=VAR_DOMAIN, 
    is_a_field_of_this=is_a_field_of_this@entry=0x0) at ../../gdb/symtab.c:1226
#13 0x00000000005b55bc in language_bool_type (
    la=0x7ac860 <cplus_language_defn>, gdbarch=<optimized out>)
    at ../../gdb/language.c:964
#14 0x000000000053c7dd in evaluate_subexp_standard (
    expect_type=expect_type@entry=0x0, exp=exp@entry=0x4c9552e0, 
    pos=0x7fffef98d1cc, noside=noside@entry=EVAL_NORMAL)
    at ../../gdb/eval.c:2450
#15 0x0000000000613103 in evaluate_subexp_c (expect_type=0x0, exp=0x4c9552e0, 
    pos=0x7fffef98d1cc, noside=EVAL_NORMAL) at ../../gdb/c-lang.c:704
#16 0x000000000053a3a2 in evaluate_subexp (noside=EVAL_NORMAL, 
    pos=0x7fffef98d1cc, exp=0x4c9552e0, expect_type=0x0) at ../../gdb/eval.c:72
#17 evaluate_expression (exp=exp@entry=0x4c9552e0) at ../../gdb/eval.c:147
#18 0x0000000000514059 in breakpoint_cond_eval (exp=exp@entry=0x4c9552e0)
    at ../../gdb/breakpoint.c:4577
#19 0x0000000000586a2a in catch_errors (
    func=func@entry=0x514040 <breakpoint_cond_eval>, 
    func_args=func_args@entry=0x4c9552e0, 
    errstring=errstring@entry=0x75b4c8 "Error in testing breakpoint
condition:\n", mask=mask@entry=6) at ../../gdb/exceptions.c:546
#20 0x000000000051f940 in bpstat_check_breakpoint_conditions (ptid=..., 
    bs=0x18542b80) at ../../gdb/breakpoint.c:5113
#21 bpstat_stop_status (aspace=<optimized out>, 
    bp_addr=bp_addr@entry=46912496339759, ptid=..., ws=ws@entry=0x7fffef98d8a0)
    at ../../gdb/breakpoint.c:5275
#22 0x0000000000577ffc in handle_inferior_event (ecs=ecs@entry=0x7fffef98d880)
    at ../../gdb/infrun.c:4224
#23 0x000000000057a52a in wait_for_inferior () at ../../gdb/infrun.c:2765
#24 0x000000000057aa17 in proceed (addr=addr@entry=18446744073709551615, 
    siggnal=siggnal@entry=GDB_SIGNAL_DEFAULT, step=step@entry=0)
    at ../../gdb/infrun.c:2346
#25 0x000000000056f302 in continue_1 (all_threads=all_threads@entry=0)
    at ../../gdb/infcmd.c:736
#26 0x000000000056f451 in continue_command (args=0x0, from_tty=1)
    at ../../gdb/infcmd.c:828
#27 0x00000000006442ea in execute_command (p=0x2cb1221 "", 
    p@entry=0x2cb1220 "c", from_tty=1) at ../../gdb/top.c:487
#28 0x000000000058fd41 in command_handler (command=0x2cb1220 "c")
    at ../../gdb/event-top.c:436
#29 0x00000000005901cc in command_line_handler (rl=<optimized out>)
    at ../../gdb/event-top.c:634
#30 0x00000036fa62a7ee in rl_callback_read_char () at ../callback.c:220
#31 0x000000000058fda9 in rl_callback_read_char_wrapper (
    client_data=<optimized out>) at ../../gdb/event-top.c:164
#32 0x000000000058ea84 in process_event () at ../../gdb/event-loop.c:342
#33 0x000000000058edd7 in gdb_do_one_event () at ../../gdb/event-loop.c:406
#34 0x000000000058eff7 in start_event_loop () at ../../gdb/event-loop.c:431
#35 0x0000000000588213 in captured_command_loop (data=data@entry=0x0)
    at ../../gdb/main.c:259
#36 0x0000000000586a2a in catch_errors (
    func=func@entry=0x588200 <captured_command_loop>, 
    func_args=func_args@entry=0x0, errstring=errstring@entry=0x725cab "", 
    mask=mask@entry=6) at ../../gdb/exceptions.c:546
#37 0x0000000000588e16 in captured_main (data=data@entry=0x7fffef98dd80)
    at ../../gdb/main.c:1134
#38 0x0000000000586a2a in catch_errors (
    func=func@entry=0x588590 <captured_main>, 
    func_args=func_args@entry=0x7fffef98dd80, 
    errstring=errstring@entry=0x725cab "", mask=mask@entry=6)
    at ../../gdb/exceptions.c:546
#39 0x0000000000589a34 in gdb_main (args=args@entry=0x7fffef98dd80)
    at ../../gdb/main.c:1144
#40 0x00000000004546ce in main (argc=<optimized out>, argv=<optimized out>)
    at ../../gdb/gdb.c:34


With a probe breakpoint:

(gdb) break -probe new_string_16
(gdb) condition 5 $_probe_arg1 == 999
(gdb) info b
Num     Type           Disp Enb Address            What
5       breakpoint     keep y   <MULTIPLE>         
    stop only if $_probe_arg1 == 999
5.1                         y     0x00002aaaaaadec18 -probe new_string_16
5.2                         y     0x00002aaaaaadec38 -probe new_string_16
5.3                         y     0x00002aaaaaadec73 -probe new_string_16
5.4                         y     0x00002aaaaaadecc7 -probe new_string_16
5.5                         y     0x00002aaaaaaded2e -probe new_string_16
5.6                         y     0x00002aaaaaadf185 -probe new_string_16
5.7                         y     0x00002aaaaaae0403 -probe new_string_16
5.8                         y     0x00002aaaaaae0566 -probe new_string_16
5.9                         y     0x00002aaaaaae0775 -probe new_string_16
5.10                        y     0x00002aaaaaae0813 -probe new_string_16
5.11                        y     0x00002aaaaaae0885 -probe new_string_16
5.12                        y     0x00002aaaaaae0945 -probe new_string_16
5.13                        y     0x00002aaaaaae0b2f -probe new_string_16
5.14                        y     0x00002aaaaaae0b9b -probe new_string_16
5.15                        y     0x00002aaaaaae0cde -probe new_string_16
5.16                        y     0x00002aaaaaae0e08 -probe new_string_16
5.17                        y     0x00002aaaaaae0f2e -probe new_string_16
5.18                        y     0x00002aaaaaae105e -probe new_string_16
5.19                        y     0x00002aaaaaae119d -probe new_string_16
5.20                        y     0x00002aaaaaae19a9 -probe new_string_16
5.21                        y     0x00002aaaaaae1a79 -probe new_string_16

perf top output:

  35.18%  gdb                             [.] lookup_symbol_aux_psymtabs
  16.84%  gdb                             [.] lookup_partial_symbol.isra.3
   7.84%  gdb                             [.] symbol_natural_name
   7.82%  gdb                             [.] lookup_symbol_aux_objfile
   6.11%  gdb                             [.] strcmp_iw_ordered

attaching another gdb:

#0  0x0000000000556aa4 in lookup_symbol_aux_objfile (
    objfile=objfile@entry=0x19e12430, block_index=block_index@entry=0, 
    name=0x746ed9 "bool", domain=VAR_DOMAIN) at ../../gdb/symtab.c:1539
#1  0x0000000000556d90 in lookup_symbol_global_iterator_cb (
    objfile=0x19e12430, cb_data=0x7fffef98cc70) at ../../gdb/symtab.c:1756
#2  0x00000000005bcd11 in default_iterate_over_objfiles_in_search_order (
    gdbarch=<optimized out>, cb=0x556d70 <lookup_symbol_global_iterator_cb>, 
    cb_data=0x7fffef98cc70, current_objfile=<optimized out>)
    at ../../gdb/objfiles.c:1480
#3  0x0000000000556825 in lookup_symbol_global (
    name=name@entry=0x746ed9 "bool", block=block@entry=0x0, 
    domain=domain@entry=VAR_DOMAIN) at ../../gdb/symtab.c:1790
#4  0x0000000000657496 in lookup_symbol_file (name=name@entry=0x746ed9 "bool", 
    block=block@entry=0x0, domain=domain@entry=VAR_DOMAIN, 
    anonymous_namespace=anonymous_namespace@entry=0, search=1)
    at ../../gdb/cp-namespace.c:632
#5  0x0000000000657670 in cp_lookup_symbol_in_namespace (
    namespace=namespace@entry=0x725cab "", name=name@entry=0x746ed9 "bool", 
    block=block@entry=0x0, domain=domain@entry=VAR_DOMAIN, 
    search=search@entry=1) at ../../gdb/cp-namespace.c:255
#6  0x0000000000657bd1 in cp_lookup_symbol_namespace (scope=0x725cab "", 
    name=0x746ed9 "bool", block=0x0, domain=VAR_DOMAIN)
    at ../../gdb/cp-namespace.c:526
#7  0x0000000000556f4f in lookup_symbol_aux (is_a_field_of_this=0x0, 
    language=<optimized out>, domain=VAR_DOMAIN, block=0x0, 
    name=0x746ed9 "bool") at ../../gdb/symtab.c:1365
#8  lookup_symbol_in_language (name=<optimized out>, block=block@entry=0x0, 
    domain=domain@entry=VAR_DOMAIN, lang=<optimized out>, 
    is_a_field_of_this=is_a_field_of_this@entry=0x0) at ../../gdb/symtab.c:1211
#9  0x0000000000557022 in lookup_symbol (name=<optimized out>, 
    block=block@entry=0x0, domain=domain@entry=VAR_DOMAIN, 
    is_a_field_of_this=is_a_field_of_this@entry=0x0) at ../../gdb/symtab.c:1226
#10 0x00000000005b55bc in language_bool_type (
    la=0x7ac860 <cplus_language_defn>, gdbarch=<optimized out>)
    at ../../gdb/language.c:964
#11 0x000000000053eac4 in evaluate_subexp_standard (
    expect_type=expect_type@entry=0x0, exp=exp@entry=0x10a6ef40, 
    pos=0x7fffef98d1cc, noside=noside@entry=EVAL_NORMAL)
    at ../../gdb/eval.c:2495
#12 0x0000000000613103 in evaluate_subexp_c (expect_type=0x0, exp=0x10a6ef40, 
    pos=0x7fffef98d1cc, noside=EVAL_NORMAL) at ../../gdb/c-lang.c:704
#13 0x000000000053a3a2 in evaluate_subexp (noside=EVAL_NORMAL, 
    pos=0x7fffef98d1cc, exp=0x10a6ef40, expect_type=0x0) at ../../gdb/eval.c:72
#14 evaluate_expression (exp=exp@entry=0x10a6ef40) at ../../gdb/eval.c:147
#15 0x0000000000514059 in breakpoint_cond_eval (exp=exp@entry=0x10a6ef40)
    at ../../gdb/breakpoint.c:4577
#16 0x0000000000586a2a in catch_errors (
    func=func@entry=0x514040 <breakpoint_cond_eval>, 
    func_args=func_args@entry=0x10a6ef40, 
    errstring=errstring@entry=0x75b4c8 "Error in testing breakpoint
condition:\n", mask=mask@entry=6) at ../../gdb/exceptions.c:546
#17 0x000000000051f940 in bpstat_check_breakpoint_conditions (ptid=..., 
    bs=0x12929160) at ../../gdb/breakpoint.c:5113
#18 bpstat_stop_status (aspace=<optimized out>, 
    bp_addr=bp_addr@entry=46912496339269, ptid=..., ws=ws@entry=0x7fffef98d8a0)
    at ../../gdb/breakpoint.c:5275
#19 0x0000000000577ffc in handle_inferior_event (ecs=ecs@entry=0x7fffef98d880)
    at ../../gdb/infrun.c:4224
#20 0x000000000057a52a in wait_for_inferior () at ../../gdb/infrun.c:2765
#21 0x000000000057aa17 in proceed (addr=addr@entry=18446744073709551615, 
    siggnal=siggnal@entry=GDB_SIGNAL_DEFAULT, step=step@entry=0)
    at ../../gdb/infrun.c:2346
#22 0x000000000056f302 in continue_1 (all_threads=all_threads@entry=0)
    at ../../gdb/infcmd.c:736
#23 0x000000000056f451 in continue_command (args=0x0, from_tty=1)
    at ../../gdb/infcmd.c:828
#24 0x00000000006442ea in execute_command (p=0x2cb1221 "", 
    p@entry=0x2cb1220 "c", from_tty=1) at ../../gdb/top.c:487
#25 0x000000000058fd41 in command_handler (command=0x2cb1220 "c")
    at ../../gdb/event-top.c:436
#26 0x00000000005901cc in command_line_handler (rl=<optimized out>)
    at ../../gdb/event-top.c:634
#27 0x00000036fa62a7ee in rl_callback_read_char () at ../callback.c:220
#28 0x000000000058fda9 in rl_callback_read_char_wrapper (
    client_data=<optimized out>) at ../../gdb/event-top.c:164
#29 0x000000000058ea84 in process_event () at ../../gdb/event-loop.c:342
#30 0x000000000058edd7 in gdb_do_one_event () at ../../gdb/event-loop.c:406
#31 0x000000000058eff7 in start_event_loop () at ../../gdb/event-loop.c:431
#32 0x0000000000588213 in captured_command_loop (data=data@entry=0x0)
    at ../../gdb/main.c:259
#33 0x0000000000586a2a in catch_errors (
    func=func@entry=0x588200 <captured_command_loop>, 
    func_args=func_args@entry=0x0, errstring=errstring@entry=0x725cab "", 
    mask=mask@entry=6) at ../../gdb/exceptions.c:546
#34 0x0000000000588e16 in captured_main (data=data@entry=0x7fffef98dd80)
    at ../../gdb/main.c:1134
#35 0x0000000000586a2a in catch_errors (
    func=func@entry=0x588590 <captured_main>, 
    func_args=func_args@entry=0x7fffef98dd80, 
    errstring=errstring@entry=0x725cab "", mask=mask@entry=6)
    at ../../gdb/exceptions.c:546
#36 0x0000000000589a34 in gdb_main (args=args@entry=0x7fffef98dd80)
    at ../../gdb/main.c:1144
#37 0x00000000004546ce in main (argc=<optimized out>, argv=<optimized out>)
    at ../../gdb/gdb.c:34

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/15826] Slow symbol lookups during conditional breakpoints

[mjw at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15826

--- Comment #1 from Mark Wielaard <mjw at redhat dot com> ---
Should have added the gdb version used:
GNU gdb (GDB) Fedora (7.6-32.fc19)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/15826] Slow symbol lookups during conditional breakpoints

[dje at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15826

dje at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at google dot com

--- Comment #2 from dje at google dot com ---
One of the sad things is that it's doing this for "bool" ... though that may be
the reason ...

Plus I wouldn't expect gdb to keep going to psymtabs.
Once yes.  Continually ... ?  Maybe if the symbol isn't found at all.

I can recreate this with a simple program that doesn't have bool in the debug
info.  Seems a bit odd for something as big as LibreOffice though.

gdb needs to be smarter about such things.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/15826] Slow symbol lookups during conditional breakpoints

[mjw at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15826

--- Comment #3 from Mark Wielaard <mjw at redhat dot com> ---
(In reply to dje from comment #2)
> I can recreate this with a simple program that doesn't have bool in the
> debug info.  Seems a bit odd for something as big as LibreOffice though.

Would you mind posting that reproducer? LibreOffice is a bit of a giant
testcase and having a smaller reproducer would be really handy.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/15826] Slow symbol lookups during conditional breakpoints

[dje at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15826

--- Comment #4 from dje at google dot com ---
---snip---
#include <unistd.h>

int x = 0;

void
forever ()
{
  while (1)
    {
      ++x;
      usleep (100000); // 0.1 second                                            
    }
}

int
main ()
{
  forever ();
  return 0;
}
---snip---

$ g++ -g foo.cc -o foo

# Following is cribbed from memory, heads up.
$ gdb gdb
(top-gdb) b lookup_symbol_aux_quick
(top-gdb) run foo
(gdb) start
(gdb) b 11   # line with usleep
(gdb) cond 2 x % 10 == 0
(gdb) c
(top-gdb) bt

or some such.

The key is that bool isn't in the debug info, and c++ expression parsing wants
to cast the value to bool, so it ultimately calls the language lookup routine
for bool, which first checks the debug info (and if that fails uses the builtin
type).

Caching lookups, especially failed ones, will help, though gdb can still be
smarter with "standard" types.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/15826] Slow symbol lookups during conditional breakpoints

[mjw at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15826

--- Comment #5 from Mark Wielaard <mjw at redhat dot com> ---
It does seem the boolean standard type is "extra special":

struct type *
language_bool_type (const struct language_defn *la,
                    struct gdbarch *gdbarch)
{
  struct language_gdbarch *ld = gdbarch_data (gdbarch,
                                              language_gdbarch_data);

  if (ld->arch_info[la->la_language].bool_type_symbol)
    {
      struct symbol *sym;

      sym = lookup_symbol (ld->arch_info[la->la_language].bool_type_symbol,
                           NULL, VAR_DOMAIN, NULL);
      if (sym)
        {
          struct type *type = SYMBOL_TYPE (sym);

          if (type && TYPE_CODE (type) == TYPE_CODE_BOOL)
            return type;
        }
    }

  return ld->arch_info[la->la_language].bool_type_default;
}

The above is why "bool" is always looked up.
Other standard types don't have this extra lookup to override the default.

cplus_language_arch_info () does set bool_type_symbol = "bool". But is that
really correct? You cannot override bool in C++ since it is a built-in type.

So, possible, untested, "fix":

diff --git a/gdb/c-lang.c b/gdb/c-lang.c
index 48a1fb0..e2201b4 100644
--- a/gdb/c-lang.c
+++ b/gdb/c-lang.c
@@ -931,7 +931,7 @@ cplus_language_arch_info (struct gdbarch *gdbarch,
   lai->primitive_type_vector [cplus_primitive_type_declong]
     = builtin->builtin_declong;

-  lai->bool_type_symbol = "bool";
+  lai->bool_type_symbol = NULL; // "bool" is always a built-in type.
   lai->bool_type_default = builtin->builtin_bool;
 }

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/15826] Slow symbol lookups during conditional breakpoints

[mjw at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15826

--- Comment #6 from Mark Wielaard <mjw at redhat dot com> ---
Sigh, although the patch in comment #5 works, and bool is a built-in type for
C++, the standard says:

§5.3.3/1, abridged:

    sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1; the
result of sizeof applied to any other fundamental type is
implementation-defined. [Note: in particular, sizeof(bool) and sizeof(wchar_t)
are implementation-defined.69)]

Footnote 69):

    sizeof(bool) is not required to be 1.

The (Itanium) C++ ABI, which GCC follows now, specifies (2.2 POD Data Types):
Type bool has size and alignment 1.

Can we easily detect the ABI used in language_bool_type?

Note that as far as I can see this special casing for bool_type was introduced
specifically for C++ (plain C doesn't do these symbol lookups). But then
adopted for all other languages introduced after that. Even if they have a
built-in boolean type with a well defined size. In those cases it IMHO doesn't
make sense to explicitly define bool_type_symbol for the language. Because it
will generate these symbol table lookups each time language_bool_type () is
called.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From gdb-prs-return-14271-listarch-gdb-prs=sources.redhat.com@sourceware.org Sun Sep 01 13:01:41 2013
Return-Path: <gdb-prs-return-14271-listarch-gdb-prs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-prs@sources.redhat.com
Received: (qmail 12745 invoked by alias); 1 Sep 2013 13:01:41 -0000
Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-prs.sourceware.org>
List-Subscribe: <mailto:gdb-prs-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-prs/>
List-Post: <mailto:gdb-prs@sourceware.org>
List-Help: <mailto:gdb-prs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: gdb-prs-owner@sourceware.org
Delivered-To: mailing list gdb-prs@sourceware.org
Received: (qmail 12719 invoked by uid 48); 1 Sep 2013 13:01:41 -0000
From: "schwab@linux-m68k.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug build/15916] gdb assumes lib(bfd,opcodes) are static
Date: Sun, 01 Sep 2013 13:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: build
X-Bugzilla-Version: 7.6
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-15916-4717-3lMJRSdFii@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15916-4717@http.sourceware.org/bugzilla/>
References: <bug-15916-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-q3/txt/msg00305.txt.bz2
Content-length: 272

https://sourceware.org/bugzilla/show_bug.cgi?id\x15916

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
Separating out libbfd is difficult as there are no ABI nor API guarantees.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/15826] Slow symbol lookups during conditional breakpoints

[mjw at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15826

--- Comment #7 from Mark Wielaard <mjw at redhat dot com> ---
BTW. I really would like to find a real solution for this. With the patch from
comment #5 I can at least run libreoffice with my conditional breakpoint
installed. It is still slow (slower than running under valgrind), but at least
it is possible. So fixing this does enable using gdb (at least for me) on a
problem that wasn't possible before.

Any ideas/suggestions/hints how the correct fix should look like?

(BTW2. With the patch from comment #5 there were no changes in the make check
test results.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/15826] Slow symbol lookups during conditional breakpoints

[mjw at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15826

--- Comment #8 from Mark Wielaard <mjw at redhat dot com> ---
Since some people asked, this is my current testcase:

int x = 0;

int
bar (int y)
{
  int flag = y < 42;
  return flag ? y : 0;
}

int
forever ()
{
  int z;
  while (x < 42)
    {
      z = x + 1;
      x = bar (z);
    }
  return z;
}

int
main ()
{
  return forever ();
}

$ g++ -g -o loop loop.c
$ gdb loop
Reading symbols from /usr/local/src/tests/loop...done.
(gdb) break bar
Breakpoint 1 at 0x4005b7: file loop.c, line 6.
(gdb) condition 1 y == 55
(gdb) run
Starting program: /usr/local/src/tests/loop 

Even though that doesn't really have a symbol table at all, it already will
show that gdb is mainly spending time in lookup_symbol_aux_objfile.

This isn't a very good testcase, except to inspect what is going on. In the
real testcase with libreoffice you can see a lot more stuff gdb spends time on
during the evaluation of a breakpoint condition (there the breakpoints are hit
often, but not like here in a loop, and libreoffice is linked against a lot
more libraries to make things a bit more interesting).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/15826] Slow symbol lookups during conditional breakpoints

[markus.mohrhard at googlemail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15826

Markus Mohrhard <markus.mohrhard at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markus.mohrhard@googlemail.
                   |                            |com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/15826] Slow symbol lookups during conditional breakpoints

[dje at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15826

dje at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |performance
          Component|breakpoints                 |symtab

--- Comment #9 from dje at google dot com ---
Hi Mark.
I tried to repro what you're seeing in gdb with your sample program in comment
#8, and failed.

If/when you have time, can you retry, and give me repro instructions?
Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/15826] Slow symbol lookups during conditional breakpoints

[mjw at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15826

--- Comment #10 from Mark Wielaard <mjw at redhat dot com> ---
It has been some time since I looked at this. The testcase in comment #8 isn't
really good, but should show that a symbol lookup is done on every condition
evaluation. The original libreoffice usage is much more interesting, but way
harder to setup (I currently don't have it setup). The actual symbol lookup
function did change with current gdb git trunk compared to when I tested it
back in September. But I think gdb is still doing too much work, especially
given that this example doesn't actually have any symbol table to speak of.

So with the program from comment #8 and g++, perf and gdb trunk:

g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
perf version 2.6.32-431.17.1.el6.x86_64.debug
GNU gdb (GDB) 7.7.50.20140603-cvs

With loop compiled with g++ as in comment #8. Just run $ sudo perf top in one
window. And gdb in another $ gdb loop.
Reading symbols from loop...done.
(gdb) break bar
Breakpoint 1 at 0x40055b: file loop.c, line 6.
(gdb) condition 1 y == 55
(gdb) run
Starting program: /tmp/loop 

Now in the perf window you will see something like:

  3.17%  libc-2.12.so                             [.] _int_malloc
  2.50%  libc-2.12.so                             [.] vfprintf
  1.79%  libc-2.12.so                             [.] _int_free
  1.37%  libpthread-2.12.so                       [.] pthread_rwlock_unlock
  1.28%  libpthread-2.12.so                       [.] pthread_rwlock_rdlock
  1.22%  libc-2.12.so                             [.] malloc_consolidate
  1.22%  gdb                                      [.] gdbarch_data
  1.20%  libc-2.12.so                             [.] __dcigettext
  1.14%  gdb                                      [.] dwarf2_frame_cache
  1.08%  libc-2.12.so                             [.] getenv
  1.05%  [kernel]                                 [k] _spin_lock
  1.02%  libc-2.12.so                             [.] __memset_sse2
  1.01%  gdb                                      [.]
lookup_minimal_symbol_by_pc_section_1


If we attach gdb to the running gdb we see how we end up in
lookup_minimal_symbol (back in September this was lookup_symbol_aux) we see:

#0  lookup_minimal_symbol_by_pc_section_1 (pc_in=<value optimized out>,
section=0x251f370, 
    want_trampoline=<value optimized out>) at
/home/mark/src/binutils-gdb/gdb/minsyms.c:568
#1  0x00000000005f11e7 in lookup_minimal_symbol_by_pc_section (pc=4195675,
section=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/minsyms.c:743
#2  0x0000000000581489 in find_pc_sect_symtab (pc=4195675, section=0x0)
    at /home/mark/src/binutils-gdb/gdb/symtab.c:2153
#3  0x000000000057ec1d in blockvector_for_pc_sect (pc=4195675, section=<value
optimized out>, pblock=
    0x7fff3a3fcad8, symtab=<value optimized out>) at
/home/mark/src/binutils-gdb/gdb/block.c:168
#4  0x000000000057ec40 in block_for_pc_sect (pc=<value optimized out>,
section=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/block.c:246
#5  0x000000000068b5d8 in inline_frame_sniffer (self=<value optimized out>,
this_frame=0x23eb710, 
    this_cache=<value optimized out>) at
/home/mark/src/binutils-gdb/gdb/inline-frame.c:218
#6  0x0000000000689c53 in frame_unwind_try_unwinder (this_frame=0x23eb710,
this_cache=0x23eb728, unwinder=0x8279c0)
    at /home/mark/src/binutils-gdb/gdb/frame-unwind.c:108
#7  0x0000000000689d4f in frame_unwind_find_by_frame (this_frame=0x23eb710,
this_cache=0x23eb728)
    at /home/mark/src/binutils-gdb/gdb/frame-unwind.c:159
#8  0x0000000000686c9b in compute_frame_id (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:457
#9  get_prev_frame_if_no_cycle (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:1783
#10 0x0000000000688ad8 in get_prev_frame_always_1 (this_frame=0x23eb640)
    at /home/mark/src/binutils-gdb/gdb/frame.c:1957
#11 get_prev_frame_always (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:1974
#12 0x0000000000688fc8 in get_prev_frame (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:2215
#13 0x00000000006891ac in unwind_to_current_frame (ui_out=<value optimized
out>, args=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/frame.c:1450
#14 0x00000000005b56f2 in catch_exceptions_with_msg (func_uiout=<value
optimized out>, func=
    0x6891a0 <unwind_to_current_frame>, func_args=0x23eb640, gdberrmsg=0x0,
mask=RETURN_MASK_ERROR)
    at /home/mark/src/binutils-gdb/gdb/exceptions.c:476
#15 0x00000000006867b0 in get_current_frame () at
/home/mark/src/binutils-gdb/gdb/frame.c:1489
#16 0x00000000005a81fe in handle_signal_stop (ecs=0x7fff3a3fcfc0) at
/home/mark/src/binutils-gdb/gdb/infrun.c:3969
#17 handle_inferior_event (ecs=0x7fff3a3fcfc0) at
/home/mark/src/binutils-gdb/gdb/infrun.c:3819
#18 0x00000000005a95bc in fetch_inferior_event (client_data=<value optimized
out>)
    at /home/mark/src/binutils-gdb/gdb/infrun.c:2921
#19 0x00000000005c0479 in fetch_inferior_event_wrapper (client_data=<value
optimized out>)
    at /home/mark/src/binutils-gdb/gdb/inf-loop.c:147
#20 0x00000000005b55fb in catch_errors (func=0x5c0470
<fetch_inferior_event_wrapper>, func_args=0x0, errstring=
    0x78beca "", mask=RETURN_MASK_ALL) at
/home/mark/src/binutils-gdb/gdb/exceptions.c:524
#21 0x00000000005c01df in inferior_event_handler (event_type=INF_REG_EVENT,
client_data=0x0)
    at /home/mark/src/binutils-gdb/gdb/inf-loop.c:55
#22 0x00000000005be4b4 in process_event () at
/home/mark/src/binutils-gdb/gdb/event-loop.c:343
#23 0x00000000005beeaf in gdb_do_one_event () at
/home/mark/src/binutils-gdb/gdb/event-loop.c:395
#24 0x00000000005bf085 in start_event_loop () at
/home/mark/src/binutils-gdb/gdb/event-loop.c:432
#25 0x00000000005b7fa3 in captured_command_loop (data=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/main.c:301
#26 0x00000000005b55fb in catch_errors (func=0x5b7f90 <captured_command_loop>,
func_args=0x0, errstring=
    0x78beca "", mask=RETURN_MASK_ALL) at
/home/mark/src/binutils-gdb/gdb/exceptions.c:524
#27 0x00000000005b8b86 in captured_main (data=<value optimized out>) at
/home/mark/src/binutils-gdb/gdb/main.c:1097
#28 0x00000000005b55fb in catch_errors (func=0x5b8180 <captured_main>,
func_args=0x7fff3a3fd360, errstring=
    0x78beca "", mask=RETURN_MASK_ALL) at
/home/mark/src/binutils-gdb/gdb/exceptions.c:524
#29 0x00000000005b7ddb in gdb_main (args=<value optimized out>) at
/home/mark/src/binutils-gdb/gdb/main.c:1105
#30 0x000000000045e375 in main (argc=<value optimized out>, argv=<value
optimized out>)
    at /home/mark/src/binutils-gdb/gdb/gdb.c:33

And gdbarch_data is reached through:

#0  gdbarch_data (gdbarch=0x2540420, data=0x23e3d60) at
/home/mark/src/binutils-gdb/gdb/gdbarch.c:4499
#1  0x0000000000634582 in dwarf2_frame_signal_frame_p (self=0x816400,
this_frame=0x23eb710, 
    this_cache=<value optimized out>) at
/home/mark/src/binutils-gdb/gdb/dwarf2-frame.c:821
#2  dwarf2_frame_sniffer (self=0x816400, this_frame=0x23eb710,
this_cache=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/dwarf2-frame.c:1420
#3  0x0000000000689c53 in frame_unwind_try_unwinder (this_frame=0x23eb710,
this_cache=0x23eb728, unwinder=0x816400)
    at /home/mark/src/binutils-gdb/gdb/frame-unwind.c:108
#4  0x0000000000689d4f in frame_unwind_find_by_frame (this_frame=0x23eb710,
this_cache=0x23eb728)
    at /home/mark/src/binutils-gdb/gdb/frame-unwind.c:159
#5  0x0000000000686c9b in compute_frame_id (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:457
#6  get_prev_frame_if_no_cycle (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:1783
#7  0x0000000000688ad8 in get_prev_frame_always_1 (this_frame=0x23eb640)
    at /home/mark/src/binutils-gdb/gdb/frame.c:1957
#8  get_prev_frame_always (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:1974
#9  0x0000000000688fc8 in get_prev_frame (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:2215
#10 0x00000000006891ac in unwind_to_current_frame (ui_out=<value optimized
out>, args=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/frame.c:1450
#11 0x00000000005b56f2 in catch_exceptions_with_msg (func_uiout=<value
optimized out>, func=
    0x6891a0 <unwind_to_current_frame>, func_args=0x23eb640, gdberrmsg=0x0,
mask=RETURN_MASK_ERROR)
    at /home/mark/src/binutils-gdb/gdb/exceptions.c:476
#12 0x00000000006867b0 in get_current_frame () at
/home/mark/src/binutils-gdb/gdb/frame.c:1489
#13 0x00000000005a81fe in handle_signal_stop (ecs=0x7fff3a3fcfc0) at
/home/mark/src/binutils-gdb/gdb/infrun.c:3969
#14 handle_inferior_event (ecs=0x7fff3a3fcfc0) at
/home/mark/src/binutils-gdb/gdb/infrun.c:3819
#15 0x00000000005a95bc in fetch_inferior_event (client_data=<value optimized
out>)
    at /home/mark/src/binutils-gdb/gdb/infrun.c:2921
#16 0x00000000005c0479 in fetch_inferior_event_wrapper (client_data=<value
optimized out>)
    at /home/mark/src/binutils-gdb/gdb/inf-loop.c:147
#17 0x00000000005b55fb in catch_errors (func=0x5c0470
<fetch_inferior_event_wrapper>, func_args=0x0, errstring=
    0x78beca "", mask=RETURN_MASK_ALL) at
/home/mark/src/binutils-gdb/gdb/exceptions.c:524
#18 0x00000000005c01df in inferior_event_handler (event_type=INF_REG_EVENT,
client_data=0x0)
    at /home/mark/src/binutils-gdb/gdb/inf-loop.c:55
#19 0x00000000005be4b4 in process_event () at
/home/mark/src/binutils-gdb/gdb/event-loop.c:343
#20 0x00000000005beeaf in gdb_do_one_event () at
/home/mark/src/binutils-gdb/gdb/event-loop.c:395
#21 0x00000000005bf085 in start_event_loop () at
/home/mark/src/binutils-gdb/gdb/event-loop.c:432
#22 0x00000000005b7fa3 in captured_command_loop (data=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/main.c:301
#23 0x00000000005b55fb in catch_errors (func=0x5b7f90 <captured_command_loop>,
func_args=0x0, errstring=
    0x78beca "", mask=RETURN_MASK_ALL) at
/home/mark/src/binutils-gdb/gdb/exceptions.c:524
#24 0x00000000005b8b86 in captured_main (data=<value optimized out>) at
/home/mark/src/binutils-gdb/gdb/main.c:1097
#25 0x00000000005b55fb in catch_errors (func=0x5b8180 <captured_main>,
func_args=0x7fff3a3fd360, errstring=
    0x78beca "", mask=RETURN_MASK_ALL) at
/home/mark/src/binutils-gdb/gdb/exceptions.c:524
#26 0x00000000005b7ddb in gdb_main (args=<value optimized out>) at
/home/mark/src/binutils-gdb/gdb/main.c:1105
#27 0x000000000045e375 in main (argc=<value optimized out>, argv=<value
optimized out>)
    at /home/mark/src/binutils-gdb/gdb/gdb.c:33

Why is gdb even trying to unwind the frame here?

And finally the vfprintf that seems to eat up most of the time comes from:

#0  _IO_vfprintf_internal (s=0x7fff3a3fc860, format=0x8f47ff "%lx",
ap=0x7fff3a3fc9c0) at vfprintf.c:236
#1  0x0000003643c6fa52 in _IO_vsnprintf (string=0xbec610 "", maxlen=<value
optimized out>, format=0x8f47ff "%lx", 
    args=0x7fff3a3fc9c0) at vsnprintf.c:120
#2  0x00000000006ad3e5 in xsnprintf (str=<value optimized out>, size=50,
format=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/common/common-utils.c:148
#3  0x00000000006b47ba in phex_nz (l=<value optimized out>, sizeof_l=<value
optimized out>)
    at /home/mark/src/binutils-gdb/gdb/common/print-utils.c:212
#4  0x00000000006b4912 in hex_string (num=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/common/print-utils.c:233
#5  0x00000000006357db in dwarf2_frame_cache (this_frame=0x23eb710,
this_cache=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/dwarf2-frame.c:1184
#6  0x0000000000635cae in dwarf2_frame_this_id (this_frame=0x23eb710,
this_cache=<value optimized out>, this_id=
    0x23eb770) at /home/mark/src/binutils-gdb/gdb/dwarf2-frame.c:1270
#7  0x0000000000686ac3 in compute_frame_id (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:461
#8  get_prev_frame_if_no_cycle (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:1783
#9  0x0000000000688ad8 in get_prev_frame_always_1 (this_frame=0x23eb640)
    at /home/mark/src/binutils-gdb/gdb/frame.c:1957
#10 get_prev_frame_always (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:1974
#11 0x0000000000688fc8 in get_prev_frame (this_frame=0x23eb640) at
/home/mark/src/binutils-gdb/gdb/frame.c:2215
#12 0x00000000006891ac in unwind_to_current_frame (ui_out=<value optimized
out>, args=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/frame.c:1450
#13 0x00000000005b56f2 in catch_exceptions_with_msg (func_uiout=<value
optimized out>, func=
    0x6891a0 <unwind_to_current_frame>, func_args=0x23eb640, gdberrmsg=0x0,
mask=RETURN_MASK_ERROR)
    at /home/mark/src/binutils-gdb/gdb/exceptions.c:476
#14 0x00000000006867b0 in get_current_frame () at
/home/mark/src/binutils-gdb/gdb/frame.c:1489
#15 0x00000000005a81fe in handle_signal_stop (ecs=0x7fff3a3fcfc0) at
/home/mark/src/binutils-gdb/gdb/infrun.c:3969
#16 handle_inferior_event (ecs=0x7fff3a3fcfc0) at
/home/mark/src/binutils-gdb/gdb/infrun.c:3819
#17 0x00000000005a95bc in fetch_inferior_event (client_data=<value optimized
out>)
    at /home/mark/src/binutils-gdb/gdb/infrun.c:2921
#18 0x00000000005c0479 in fetch_inferior_event_wrapper (client_data=<value
optimized out>)
    at /home/mark/src/binutils-gdb/gdb/inf-loop.c:147
#19 0x00000000005b55fb in catch_errors (func=0x5c0470
<fetch_inferior_event_wrapper>, func_args=0x0, errstring=
    0x78beca "", mask=RETURN_MASK_ALL) at
/home/mark/src/binutils-gdb/gdb/exceptions.c:524
#20 0x00000000005c01df in inferior_event_handler (event_type=INF_REG_EVENT,
client_data=0x0)
    at /home/mark/src/binutils-gdb/gdb/inf-loop.c:55
#21 0x00000000005be4b4 in process_event () at
/home/mark/src/binutils-gdb/gdb/event-loop.c:343
#22 0x00000000005beeaf in gdb_do_one_event () at
/home/mark/src/binutils-gdb/gdb/event-loop.c:395
#23 0x00000000005bf085 in start_event_loop () at
/home/mark/src/binutils-gdb/gdb/event-loop.c:432
#24 0x00000000005b7fa3 in captured_command_loop (data=<value optimized out>)
    at /home/mark/src/binutils-gdb/gdb/main.c:301
#25 0x00000000005b55fb in catch_errors (func=0x5b7f90 <captured_command_loop>,
func_args=0x0, errstring=
    0x78beca "", mask=RETURN_MASK_ALL) at
/home/mark/src/binutils-gdb/gdb/exceptions.c:524
#26 0x00000000005b8b86 in captured_main (data=<value optimized out>) at
/home/mark/src/binutils-gdb/gdb/main.c:1097
#27 0x00000000005b55fb in catch_errors (func=0x5b8180 <captured_main>,
func_args=0x7fff3a3fd360, errstring=
    0x78beca "", mask=RETURN_MASK_ALL) at
/home/mark/src/binutils-gdb/gdb/exceptions.c:524
#28 0x00000000005b7ddb in gdb_main (args=<value optimized out>) at
/home/mark/src/binutils-gdb/gdb/main.c:1105
#29 0x000000000045e375 in main (argc=<value optimized out>, argv=<value
optimized out>)
    at /home/mark/src/binutils-gdb/gdb/gdb.c:33

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/15826] Slow symbol lookups during conditional breakpoints

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=15826

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #11 from Tom Tromey <tromey at sourceware dot org> ---
This code is kind of lame because it doesn't pass a block through
to the lookup.  So if you did have a multi-arch program or one
where some parts were compiled with a different ABI, gdb could still
pick the wrong 'bool'.

Fixing the calls in eval.c isn't too hard.  For example, type
lookups like this could be memoized, either in the expression
operation object, or in the expression itself.  The key thing
here is to make sure the cache is invalidated correctly,
see the 'uses_objfile' method.

Fixing eval.c isn't enough in all cases, the other value code
calls these things as well in some spots.  Those are harder to
fix.

-- 
You are receiving this mail because:
You are on the CC list for the bug.