Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could not debug into a generic method defined in an external crate #19228

Closed
magic003 opened this issue Nov 23, 2014 · 2 comments · Fixed by #22235
Closed

Could not debug into a generic method defined in an external crate #19228

magic003 opened this issue Nov 23, 2014 · 2 comments · Fixed by #22235
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)

Comments

@magic003
Copy link

Reproduce Steps

  1. Create a project using cargo new test_rust
  2. Edit the lib.rs file to:
pub trait HasArea {                                                             
    fn area(&self) -> f64 {                                                     
        0f64                                                                    
    }                                                                           
}  
pub fn print_area<T: HasArea>(shape: T) -> f64{                                 
    shape.area()                                                                
} 
fn main() {
    struct Square {                                                             
        side: f64,                                                              
    }                                                                                  
    impl HasArea for Square {                                                   
         fn area(&self) -> f64 {                                                 
            self.side * self.side                                               
         }                                                                       
    }                                                                                

    let s = Square {                                                            
        side: 20f64,                                                            
    };                                                                          

    let b = print_area(s);                                                          
    println!("Area: {}", b);                                                    
}  

Basically, it defines a trait and a generic method which accepts it as an argument.
3. Run rustc -g src/lib.rs to compile it and run gdb lib to debug. It could step into the print_area() function and the result is correct as well.
4. If I move the main() function into a standalone file main.rs and referece this library using external crate test_rust, call cargo build to build the library(I already set the debug flag in Cargo.toml) and run rustc -g -extern test_rust=target/libXXXX main.rs. I could not debug into the print_area() function, though the running result is correct. In gdb, it just goes to next line instead of going to the function definition.

Please note if I don't use generic for the function, both cases are working as expected.

OS

Archlinux x86_64

Rust version

rustc 0.13.0-nightly (81eeec0 2014-11-21 23:16:48 +0000)
binary: rustc
commit-hash: 81eeec0
commit-date: 2014-11-21 23:16:48 +0000
host: x86_64-unknown-linux-gnu
release: 0.13.0-nightly

@jdm jdm added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Nov 23, 2014
@jdm
Copy link
Contributor

jdm commented Nov 23, 2014

cc me

@michaelwoerister
Copy link
Member

Thanks for the report, @magic003!

This is a known shortcoming of debuginfo in Rust at the moment:
When you compile a crate exporting a generic function then the AST of the function is encoded in the crates metadata. Unfortunately, this encoded AST does not contain any source locations anymore (there's an issue open about this somewhere but I wasn't able to dig it up).

When an external crate is referenced while compiling another crate, the ASTs of any generic functions from the external crate get copied into the current compilation so that the compiler can treat them mostly like normal, 'local' generic function definitions. At that point, there is no way of emitting source locations in the generated debuginfo for the function, since this information has been lost when initially compiling the external crate.

As soon as we implement that source locations are saved in the ASTs of generic functions, this should just work when compiling and using things on one machine.

bors added a commit that referenced this issue Mar 4, 2015
…oerister

This allows to create proper debuginfo line information for items inlined from other crates (e.g. instantiations of generics). Only the codemap's 'metadata' is stored in a crate's metadata. That is, just filename, positions of line-beginnings, etc. but not the actual source code itself.

Crate metadata size is increased by this change because spans in the encoded ASTs take up space now:
```
                BEFORE    AFTER
libcore         36 MiB    39.6 MiB    +10%
libsyntax       51.1 MiB  60.5 MiB    +18.4%
libcollections  11.2 MiB  12.8 MiB    +14.3%
```
This only affects binaries containing metadata (rlibs and dylibs), executables should not be affected in size. 

Fixes #19228 and probably #22226.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants