Nie można debugować niczego poza plikiem wykonywalnym. Debugery działają poprzez sprawdzenie pamięci uruchomionego procesu; bez pliku wykonywalnego nie można wykonać procesu.
Zakładając te dwa pliki:
src/lib.rs
pub fn add_one(i: u8) -> u8 {
i + 2
}
#[test]
fn inline_test() {
assert_eq!(2, foo::add_one(1));
}
tests/awesome.rs
extern crate foo;
#[test]
fn a_test() {
assert_eq!(6, foo::add_one(5));
}
Po uruchomieniu cargo build
lub cargo test
, binaria testowe zostanie utworzony wKatalog. W tym przypadku istnieje jeden plik binarny o nazwie foo-69521add8c82059a
i jeden o nazwie awesome-4a24b21e22bc042a
. Uruchomienie któregokolwiek programu uruchamia ten zestaw testów. Wszystkie testy rdzy działają w ten sposób - generowany jest plik wykonywalny, a jego uruchomienie (być może z odpowiednim zestawem flag linii poleceń) spowoduje wykonanie testu.
Ten plik wykonywalny jest to, czego potrzebujesz do debugowania w GDB lub LLDB:
$ rust-lldb target/debug/awesome-4a24b21e22bc042a
(lldb) br set -r '.*add_one.*'
(lldb) r
Process 59413 launched: '/private/tmp/foo/target/debug/awesome-4a24b21e22bc042a' (x86_64)
running 1 test
Process 59413 stopped
* thread #2: tid = 0xe9637, 0x0000000100038a3e awesome-4a24b21e22bc042a`foo::add_one::ha28bd7bf9dda9f1d + 14 at lib.rs:2, name = 'a_test', stop reason = breakpoint 1.1
frame #0: 0x0000000100038a3e awesome-4a24b21e22bc042a`foo::add_one::ha28bd7bf9dda9f1d + 14 at lib.rs:2
1 pub fn add_one(i: u8) -> u8 {
-> 2 i + 2
3 }
rustc -g --crate-type lib libr.rs
ten sposób unika się stosując ciężarowy, który większość ludzi nie będzie chciał robić. Ważnym aspektem tej linii jest flaga -g
, która instruuje kompilator, aby dodał informacje debugowania. cargo build
lub cargo test
domyślnie kompiluje się w trybie debugowania. Możesz również build your tests in release mode.
Czy są testy w tej bibliotece, które chcesz debugować? – user25064
Żadne testy nie są w /tests/raindrops.rs - ale tak naprawdę, chcę debugować testy lub wywołania przez te testy – xetra11