rust_fail is not exported when using "extern crate rustc"

[kemurphy]

No description provided.

[alexcrichton]

Can you elaborate on how you discovered this? It appears that breakpoints on rust_fail still seem to work?

[kemurphy]

Huh, okay looks like there's a specific trigger for this (namely, extern crate rustc):

$ cat lol.rs
extern crate rustc;
fn main() { fail!() }
$ rustc --version
rustc 0.12.0-pre (756b7b23c 2014-08-02 21:51:10 +0000)
$ rustc lol.rs -g
$ nm lol | ack rust_fail
$ gdb
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) break rust_fail
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) q
$ 

[alexcrichton]

This looks like it's working as intended. When you link to rustc you end up dynamically linking to libstd, so this really is a symbol which will become available on a future shared library load.

If you say y to the prompt and then trigger a failure the breakpoint trips. Closing for now, but feel free to reopen if it's still a problem!

[kemurphy]

I cannot reopen this for some reason, but this is still a bug. I filed this in the first place because the breakpoint doesn't get hit; indeed, pressing 'y' and running the program yields a fail with no breakpoint hit and rust_fail left unresolved.

$ gdb lol
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lol...done.
(gdb) breka rust_fail
Undefined command: "breka".  Try "help".
(gdb) break rust_fail
Function "rust_fail" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_fail) pending.
(gdb) r
Starting program: /home/kemurphy/lol 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
task '<main>' failed at 'explicit failure', lol.rs:2
[Inferior 1 (process 23728) exited with code 0145]

As an aside I'm genuinely surprised that this is expected behavior. The fact that librustc links against libstd dynamically shouldn't force my program into linking against libstd dynamically as well. I would probably only expect this behavior I'm seeing if I wrote extern crate librustrt. Also, the fact that rust_fail doesn't show up with nm still seems weird anyway, given that other librustrt symbols show up:

$ nm lol | ack begin_unwind
0000000000400970 t _ZN6unwind12begin_unwind20h7301209117934134866E
                 U _ZN6unwind18begin_unwind_inner20h8989957d4b709f80B8dE
$ gdb lol
GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lol...done.
(gdb) break _ZN6unwind12begin_unwind20h7301209117934134866E
Breakpoint 1 at 0x400970
(gdb) r
Starting program: /home/kemurphy/lol 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Breakpoint 1, 0x0000000000400970 in unwind::begin_unwind::h7301209117934134866 ()

[alexcrichton]

The rust_fail symbol itself is not inlined nor generic, so it does not cross the crate boundary. It lives in librustrt and will always live there regardless of how you link to it. Other symbols like begin_unwind are generic or may be inlined, meaning they may appear in the local crate (in addition to librustrt)

Choosing how you link to the standard library (dynamic vs static) is not currently a fine-grained choice you can make. The compiler maximizes the number of dynamic libraries linked against if any library linked is a dynamic library, and because the standard library is distributed as a dynamic library it is linked against dynamically.

Can you also give some more information about your setup, the exact contents of files, etc? For example, this works for me:

$ cat foo.rs 
extern crate rustc;
fn main() { fail!() }
$ rustc -v
rustc 0.12.0-pre-nightly (25741603f 2014-08-03 23:46:10 +0000)
$ rustc foo.rs -g 
$ gdb ./foo 
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./foo...done.
(gdb) b rust_fail
Function "rust_fail" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_fail) pending.
(gdb) r
Starting program: /home/alex/code/rust2/foo 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
task '<main>' failed at 'explicit failure', foo.rs:2

Breakpoint 1, 0x00007ffff7849dc0 in rust_fail () from /home/alex/code/rust/lib/librustrt-4e7c5e5c.so
(gdb) 

[kemurphy]

The only file involved is lol.rs:

$ cat lol.rs
extern crate rustc;
fn main() { fail!() }

Rust is installed from @thestinger's repository on my machine. Could it be that your rustc was compiled with -g or something? (@msullivan weren't you able to reproduce this on your machine as well this weekend?)

[alexcrichton]

That file doesn't fail, so why would you expect rust_fail to be hit?

[kemurphy]

Erm, sorry, I mispasted and was just amending the comment -- you can see from the gdb log that it does in fact fail.

[steveklabnik]

I'm not 100% sure 'codegen' is the right tag here, but it's close.

[alexcrichton]

This seems to work today, so presumably it may have been fixed in the meantime, so closing.