[Bug gdb/30224] New: Rust bt fail after the fix Fix "start" for D, Rust, etc

[Bug gdb/30224] New: Rust bt fail after the fix Fix "start" for D, Rust, etc

[roidinev at gmail dot com]

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

            Bug ID: 30224
           Summary: Rust bt fail after the fix Fix "start" for D, Rust,
                    etc
           Product: gdb
           Version: 13.1
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: roidinev at gmail dot com
  Target Milestone: ---

Before the commit, gdb use plain main for rust program. Now it use full name
such as binaryname::main to lookup. 
But if fun in main have clousure , or linked with ffi. Once bt , then
get_prev_frame-->inside_main_func(this_frame) will be called.
In inside main_func, will use the full name binaryname::main to lookup, which
will be not found, lead to the error: 
```
../../gdb/frame.c:2555: internal-error: inside_main_func: Assertion `block !=
nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x5631a7be9279 gdb_internal_backtrace_1
        ../../gdb/bt-utils.c:122
0x5631a7be9326 _Z22gdb_internal_backtracev
        ../../gdb/bt-utils.c:168
0x5631a824ac99 internal_vproblem
        ../../gdb/utils.c:401
0x5631a824b0b0 _Z15internal_verrorPKciS0_P13__va_list_tag
        ../../gdb/utils.c:481
0x5631a84100b5 _Z18internal_error_locPKciS0_z
        ../../gdbsupport/errors.cc:58
0x5631a7e1de86 inside_main_func
        ../../gdb/frame.c:2555
0x5631a7e1e1e2 _Z14get_prev_frame14frame_info_ptr
        ../../gdb/frame.c:2620
0x5631a800bef6 _Z26frame_info_to_frame_object14frame_info_ptr
        ../../gdb/python/py-frame.c:360
```
I want to fix this issue and submit a pr. Need some explanation and help.
One method: when lookup symbol , if we get full name  and main language is
rust, then fallback to use plain main to lookup.  It is known before the
commit, rust still use the plain main. 

One method: if we insist with full name  after the new dwarf indexer, then
where   
should the fix go?

Note: if empty main fn  or if main fn  did not have closure in it, will not
crash.
```
fn main() {
   println!("{}", std::env::var("RUST_LOG").unwrap_or_else(|_|
"error1".to_string())); //crash 
   //println!("{}", std::env::var("RUST_LOG").unwrap_or("error2".to_string())); 
   //this is ok
}
```

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

[Bug gdb/30224] Rust bt fail after the fix Fix "start" for D, Rust, etc

[roidinev at gmail dot com]

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

--- Comment #1 from baul jianguo <roidinev at gmail dot com> ---
Test method: Just gdb binary; start; bt.

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

[Bug rust/30224] Rust bt fail after the fix Fix "start" for D, Rust, etc

[roidinev at gmail dot com]

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

baul jianguo <roidinev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|gdb                         |rust

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

[Bug rust/30224] Rust bt fail after the fix Fix "start" for D, Rust, etc

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
Thanks for the analysis.
There's already a fix pending, I'm going to put it in shortly.

*** This bug has been marked as a duplicate of bug 30158 ***

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