Debugging tokio with BugStalker

[godzie44]

Hi, i'm a developer of the OS debugger for rust named bugstalker.

At the moment I am focused on adding the ability to debug asynchronous applications. And for tokio there are already some working ideas and functionality (see this or this), and perhaps there will be more in the future.

But I have encountered a rather obvious problem - I cannot rely on the internal structures of tokio because they can change between different versions. Is it possible to get help from you in this? For example, for the debugger to work minimally with different versions of tokio, it would be enough to create a constant current version in the code (ex. const TOKIO_V: &str = "1.41.0" will be enought) so that the debugger could choose how to analyze the runtime. Of course, ideally it would be cool to have other points in the code that would be stable from the debugger's point of view.

[mox692]

For example, for the debugger to work minimally with different versions of tokio, it would be enough to create a constant current version in the code

I think this doesn't exist in tokio.

I cannot rely on the internal structures of tokio

Just out of curiosity, which part of tokio are you taking care of?

[godzie44]

I think this doesn't exist in tokio.

Yep, and this may be looks weird. But how about add some information about tokio version into one of ELF sections (for example in .note). This is exactly what some compilers do to provide hints to third party tools such as a debugger.

Just out of curiosity, which part of tokio are you taking care of?

For example runtime::Context, which i using for taken information about worker and tasks in the runtime. In addition, I use other hacks, in order to recognize a block_on thread i search for a frame with the run_task function and build a backtrace of the task that is executed in this function. Of course, it would be strange to ask to "freeze" such things, but if I can determine at least the runtime version from another process, this would already allow me to make specialized implementations.

[mox692]

add some information about tokio version into one of ELF sections

I'm not sure if tokio would accept this. Is there a userland library that does this kind of things?

Rather than exposing version variable, if you have a specific feature request that exposes some sort of internal states in a way that is not too intrusive and doesn't break by internal code change, I think you could submit it as a feature request.

[godzie44]

I'm not sure if tokio would accept this. Is there a userland library that does this kind of things?

This can be done without any dependencies using compiler link_section macro and this standard, example implementation:

const NAME: &str = "version";
const VERSION: &str = env!("CARGO_PKG_VERSION");

const fn size_aligned(initial: usize) -> usize {
    let mut size = initial;

    let tail = initial % 4;
    if tail != 0 {
        let pad = 4 - tail;
        size += pad;     
    }

    assert!(size % 4 == 0);
    size
}

// zero byte at name and
const NAME_BUF_SIZE: usize = size_aligned(NAME.len() + 1);
const VER_BUF_SIZE: usize = size_aligned(VERSION.len());

#[repr(C, align(4))]
pub struct Note {
    namesz: u32,
    descsz: u32,
    kind: u32,
    name: [u8; NAME_BUF_SIZE],
    desc: [u8; VER_BUF_SIZE],
}

const fn create_ver_note() -> Note {
    let mut name_buf = [0u8; NAME_BUF_SIZE];
    let mut ver_buf = [0u8; VER_BUF_SIZE];

    let mut i: usize = 0;
    while i < NAME.len() {
        name_buf[i] = NAME.as_bytes()[i];
        i += 1;
    }

    let mut i: usize = 0;
    while i < VERSION.len() {
        ver_buf[i] = VERSION.as_bytes()[i];
        i += 1;
    }

    Note {
        namesz: NAME.len() as u32 + 1,
        descsz: VERSION.len() as u32,
        kind: 1,
        name: name_buf,
        desc: ver_buf,
    }
}

#[link_section = ".note.tokio"]
#[used]
static SOME_NOTE: Note = create_ver_note();

fn main() {
    println!("Hello, world!");
}

Now check it with readelf

❯ readelf target/debug/example -p .note.tokio

String dump of section '.note.tokio':
  [     c]  version
  [    14]  0.1.0

[Darksonn]

Exposing a just a version number is not necessarily unreasonable. You can file a feature request. However, I would like some information about prior art; how do other libraries expose their version numbers? What happens if there are multiple copies of Tokio?

[godzie44]

You can file a feature request

Thanks, i will do it, and try to give more context and options for solving my problems

However, I would like some information about prior art; how do other libraries expose their version numbers

I have no idea, this case may be sort of unique, cause other languages have "in box" async runtime (for example golang), so the debugger can rely on some things. Or some languages like C/C++ do not care about the convenience of debugging asynchronous applications.

What happens if there are multiple copies of Tokio?

Something like that:

readelf target/debug/test_link_section -p .note.tokio

String dump of section '.note.tokio':
  [     c]  version
  [    14]  1.41.0
  [    28]  version
  [    30]  1.41.0

Also, I think the code above can only be executed during debug build of the application.