Created attachment 13491 [details] reproducer program There seems to be a performance regression from 9.2 to 10.2 that is observable in the time to run the following command on the attached reproducer program. This has been used to benchmark the performance of conditional breakpoints. $ gcc --version gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 $ gcc -g repro.c $ ./gdb --batch --ex "b foo if bar==0x7ffffff" --ex "run" --args ./a.out Also attached is a log from the libera.chat #gdb channel where this regression was discussed. As can be seen in the attached chat log, bisection by Simon suggests that this commit is to blame: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1009d92fc621bc4d017029b90a5bfab16e17fde5 I'm not currently in a position to delve deeper into this, so I'm posting here in case anyone wants to pick it up.
Created attachment 13492 [details] #gdb chatlog Attached chatlog
Things to investigate: - We do a lot of work finding tailcalls even though no tailcalls are involved the test case. Is there a way we can do less work in this case? - On the fast path, while looking for tailcalls, a NO_ENTRY_VALUE_ERROR exception is thrown. It's probably not good to rely on exceptions being thrown in the normal path of the program, maybe try to change that with functions returning nullptr if they don't find anything.