Parameterized struct doesn't get debug symbols for any of its methods

[jdm]

Sorry, the best testcase I have right now is Servo master. If you run the binary under gdb and try to break anywhere in the compositing crate, the symbols just don't exist. You can't break by filename either. You can break on mangled symbols, but there are no source positions. Other crates (like script, for example) work perfectly fine.

[jdm]

cc @michaelwoerister

[michaelwoerister]

Does dwarfdump show any debuginfo in there? I presume this is under Linux because of gdb. Does the same thing occur on OSX?

[jdm]

This is on OS X, actually. gdb version is 7.8.1.

[jdm]

Any suggestions on how to run dwarfdump on an rlib? Looks like I may also need to build the corresponding llvm-dwarfdump to the version Rust is using, too.

[jdm]

Actually, the stock OS X dwarfdump shows a lot of output on the object file I was able to extract from the rlib using ar. That's interesting.

[jdm]

0x000029a0:                 TAG_namespace [2] *
                             AT_name( "handle_load_url_msg" )

0x000029a5:                     TAG_variable [19]
                                 AT_name( "LOC" )
                                 AT_type( {0x000038a3} ( LogLocation ) )
                                 AT_external( 0x01 )
                                 AT_decl_file( "/Users/jdm/src/dev-servo/components/compositing/<log macros>" )
                                 AT_decl_line( 3 )
                                 AT_declaration( 0x01 )
                                 AT_MIPS_linkage_name( "_ZN11compositing13constellation23Constellation<LTF, STF>19handle_load_url_msg3LOCE" )

0x000029b6:                     TAG_variable [25]
                                 AT_name( "__STATIC_FMTSTR" )
                                 AT_type( {0x00003705} ( &[&str] ) )
                                 AT_external( 0x01 )
                                 AT_decl_file( "/Users/jdm/src/dev-servo/components/compositing/constellation.rs" )
                                 AT_decl_line( 805 )
                                 AT_declaration( 0x01 )
                                 AT_MIPS_linkage_name( "_ZN11compositing13constellation23Constellation<LTF, STF>19handle_load_url_msg15__STATIC_FMTSTRE" )

0x000029c8:                     NULL

That's the function I was trying to break in. Maybe it's a problem due to the parameterization of Constellation? http://mxr.mozilla.org/servo/source/components/compositing/constellation.rs#344

[michaelwoerister]

Yeah, the space in the linkage name looks like trouble. But it's still strange that you can't break anywhere.

[jdm]

It appears that every method of Constellation has no corresponding subprogram, and it's only when trying to set breakpoints inside of them that gdb claims that constellation.rs isn't recognised. Setting breakpoints inside functions that are known (like the NavigationContext ones) works fine.

[michaelwoerister]

Oh, wait, these are all generic methods then, right? Is there any chance that you are trying to break in an inlined version of such a method, i.e. the concrete method body got instantiated in another crate?

[jdm]

http://mxr.mozilla.org/servo/source/components/compositing/constellation.rs#804 looks big enough that I wouldn't expect it to be inlined. Additionally, the method is only generic over the enclosing struct types; it doesn't have any of its own type parameters.

[michaelwoerister]

The question is: Where is the method called from? If it's called from another crate then this would be a duplicate of #19228. That the type parameters are on the impl should not make a difference (I think) since for different type-args different machine code versions of the function have to be generated.

[jdm]

It's called from Constellation::handle_request, which is called from Constellation::run, which is called from Constellation::start, which is called from the servo crate (http://mxr.mozilla.org/servo/source/components/servo/lib.rs#105).

[michaelwoerister]

That seems consistent with my theory: The Constellation methods will only be instantiated in the servo crate, where span information on them is not available anymore. PR #22235 will hopefully fix this.

[michaelwoerister]

Please give this another try, now that #22235 has landed.

[jdm]

I've set breakpoints in these methods since the fix landed, so I claim this works now :)