Created attachment 14785 [details]
Proposed solution v1

I guess the massive dis-assembler slowdown is caused by searching the mapping symbol, so I try to re-write the code to increase the dump.  Please see the attached for the details, and and FIXME there should be a better solution.

Anyway, it did not see significant improvement when running the gcc regression again...  So maybe it just work for some special cases, or still have other reason that slow down the whole thing, not really sure about that.

The master branch has been updated by Nelson Chu <nelsonc1225@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c2f60ac565f1d369fde98146a16f1d3ef79e1000

commit c2f60ac565f1d369fde98146a16f1d3ef79e1000
Author: Kito Cheng <kito.cheng@sifive.com>
Date:   Mon Apr 17 20:16:33 2023 +0800

    RISC-V: Cache the latest mapping symbol and its boundary.
    
    This issue was reported from https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1188
    
    Current flow:
    1) Scan any mapping symbol less than this instruciton.
    2) If not found, did a backward search.
    
    The flow seems not big issue, let run an example here:
    
    $x:
    0x0 a   <--- Found at step 1
    0x4 b   <--- Not found in step 1, but found at step 2
    0x8 c   <--- Not found in step 1, but found at step 2
    $d
    0x12 .word 1234 <-- Found at step 1
    
    The instruciton didn't have the same address with mapping symbol will
    still did backward search again and again.
    
    So the new flow is:
    1) Use the last mapping symbol status if the address is still within the range
       of the current mapping symbol.
    2) Scan any mapping symbol less than this instruciton.
    3) If not found, did a backward search.
    4) If a proper mapping symbol is found in either step 2 or 3, find its boundary,
       and cache that.
    
    Use the same example to run the new flow again:
    
    $x:
    0x0 a   <--- Found at step 2, the boundary is 0x12
    0x4 b   <--- Cache hit at step 1, within the boundary.
    0x8 c   <--- Cache hit at step 1, within the boundary.
    $d
    0x12 .word 1234 <-- Found at step 2, the boundary is the end of section.
    
    The disassemble time of the test cases has been reduced from ~20 minutes to ~4
    seconds.
    
    opcode/ChangeLog
            PR 30282
            * riscv-dis.c (last_map_symbol_boundary): New.
            (last_map_state): New.
            (last_map_section): New.
            (riscv_search_mapping_symbol): Cache the result of latest
            mapping symbol.

Should be resolved by my patch :)