debuginfo: Generate debugging information for global variables.

[michaelwoerister]

There is no description of global variables yet. This will involve using llvm::DIBuilder::createGlobalVariable(). The implementation will be similar to those for other kinds of variables.

[michaelwoerister]

Here is a little guide on how this could be implemented. Maybe someone is interested in giving it a try.

• Wrap llvm::DIBuilder::createGlobalVariable() from src/llvm/include/llvm/DIBuilder.h. That means
  • adding a C++ to C wrapper in src/rustllvm/RustWrapper.cpp (also adding the function name to src/rustllvm/rustllvm.def.in), and
  • adding a C to Rust wrapper in src/librustc/lib/llvm.rs. The respective files contain many examples of how other functions are wrapped.
• Add a create_global_var_metadata() function to src/librustc/middle/trans/debuginfo.rs. This function should call the wrapped DIBuilder method with the appropriate arguments. See the debuginfo::file_metadata() function for a simple example of how the wrapped function can be called. The arguments needed by the DIBuilder should be made available from the create_global_var_metadata() arguments in some form or other.
• Find the right places in the trans module to call the new debuginfo::create_global_var_metadata() function. trans::consts::trans_const() looks like a very good candidate. You can take a look at trans::base::trans_stmt() for an example of how the debuginfo module is used from the outside to create the debuginfo for local variables.
• Write as many test cases as you can think of and add them to src/test/debug-info. The folder already contains many examples of how test cases are written. Some inspiration: globals should be visible from many different positions in the source code, so testing from multiple breakpoints in different scopes would be a good idea. Testing different data types also is a good idea. Testing immutable and mutable variables should be done too.
• Make a pull request, lean back and enjoy the glory of having contributed an important piece of code to the coolest project around ;)

Bonus points for also handling static variables within a function.

[cmacknz]

This sounds interesting, I'm going to start looking into it. Thanks for the guide here @michaelwoerister.

[michaelwoerister]

I've taken a look at this again some time ago and found that it would be better to use llvm::DIBuilder::createStaticVariable() instead of llvm::DIBuilder::createGlobalVariable() for this. createStaticVariable supports namespaces and Clang itself uses it for all C++ globals.createGlobalVariable is only used for something related to Objective-C interfaces, it seems.

If you have any questions or run into a dead-end just ask here and I'll be happy to help you out :)

[cmacknz]

A little update since it's been a while - I have an implementation for this and have started writing tests. Questions and/or a pull request should follow shortly once I've worked through some test cases.

[michaelwoerister]

Great. If you do a pull request, be sure to cc me, so I see it in time.

[cmacknz]

Will do.

I'm not handling mutable statics properly at the moment so I need to fix that, but immutable static globals are working with the exception of floating point types.

Floating point constants can be inspected with GDB and the whatis command reports the correct type, but the value is always reported as <optimized out>.

@michaelwoerister do you have any idea what would cause this in the underlying debug info?

[cmacknz]

Alright, so looking at the DWARF information with objdump reveals that the float types aren't getting the DW_AT_const_value attribute that is generated for the other variables. The presence of this tag on mutable statics is also why they can't be debugged properly, since it indicates that the described variable doesn't exist in the address space of the program and can never change.

I'm still perplexed as to why float constants aren't being handled properly, but I have some ideas on how to fix the issue with mutable statics at least.

[michaelwoerister]

If cmacknz@032e206 still represents the code you are testing, the problem might be that you pass v instead of g to debuginfo::create_global_var_metadata(). Apart from that your code looks great so far, very clean.
Keep up the good work!

[cmacknz]

Right, taking a closer look at the code it makes sense why using v would cause this. However, when using g it seems gdb doesn't see any of the symbols although the generated DWARF info looks more sensible.

Using v generates the following for a pub static mut B: bool = false declaration in a file called basic-types-mut-globals.rs:

 <2><2b>: Abbrev Number: 3 (DW_TAG_variable)
    <2c>   DW_AT_name        : (indirect string, offset: 0x4d64): B 
    <30>   DW_AT_type        : <0x100>  
    <34>   DW_AT_decl_file   : 1    
    <35>   DW_AT_decl_line   : 91   
    <36>   DW_AT_const_value : 0    

While using g generates the following:

 <2><2b>: Abbrev Number: 3 (DW_TAG_variable)
    <2c>   DW_AT_name        : (indirect string, offset: 0x4f36): B 
    <30>   DW_AT_type        : <0x116>  
    <34>   DW_AT_decl_file   : 1    
    <35>   DW_AT_decl_line   : 91   
    <36>   DW_AT_declaration : 1    
    <36>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x9d): _ZN23basic-types-mut-globals1BE    

The referenced DW_AT_type describes a single byte encoded as a bool in both cases.

The difference in specifying the DW_AT_MIPS_linkage_name in the 2nd case is the obvious suspect, although I'm not sure what specifically the problem is. The DWARF specification also only seems to describe DW_AT_linkage_name and not DW_AT_MIPS_linkage_name.

[cmacknz]

Dumping the symbol table I get the following, where _ZN1B20hfccf93e461ed376afaa4v0.0E looks to be the mangled name of B.

This suggests that the linkage name in the DWARF info is incorrect. Is debuginfo::NameSpaceTreeNode::mangled_name_of_contained_item() not handling this correctly? I don't have enough knowledge of Rust name mangling to answer this myself.

0000000000000000 l    df *ABS*  0000000000000000              basic-types-mut-globals.rs
000000000079a9f0 l     O .bss   0000000000000001              _ZN1B20hfccf93e461ed376afaa4v0.0E

[michaelwoerister]

The linkage name in DWARF does not actually correspond to the name of the symbol (which in Rust is not only a mangled name like in C++, but also contains some hash-value, see https://github.com/mozilla/rust/blob/master/src/librustc/back/link.rs#L454 for more info). The DWARF linkage name has just one purpose: to be printed nicely in GDB (which would not handle namespaces very well otherwise).

info variables won't list basic-types-mut-globals::B?

[cmacknz]

info variables does indeed list basic-types-mut-globals::B but attempting to use the print or whatis commands gives me a No symbol "B" in current context. error.

[cmacknz]

Comparing the DWARF information with that generated for a local variable indicates that the DW_AT_location attribute is missing, which would explain why GDB can't access it.

[michaelwoerister]

I often find it helpful in such a case to take a look at the DWARF generated by gcc and clang.

[cmacknz]

Yeah, looking at the equivalent case with GCC confirms that the DW_AT_location attribute is missing. From my understanding this means that llvm doesn't have information to figure where the variable exists in the address space of the program when it generates the DWARF information.

My preliminary suspicion is that the scope metadata provided to llvm::DIBuilder::createStaticVariable may be incomplete in some way. I'll continue digging, but if you have any insight into how llvm::DIBuilder methods figure out where variables exist within a binary it'd be appreciated.