[bug] [windows] `cargo asm` prints disassembly for some destructors instead of the requested function

[al13n321]

[bug] [windows] `cargo asm` prints disassembly for some destructors instead of the requested function

[al13n321]

If you pass --everything do you get both sections?

Yes. Here's the whole .s file (from RUSTFLAGS="--emit asm" cargo build): https://pastebin.com/gDaEZBcu . There are "_ZN4rust4main17h90585feb19c01afdE" and "?dtor$1@?0?_ZN4rust4main17h90585feb19c01afdE@4HA"

[al13n321]

This doesn't seem to be a matter of having multiple functions with the same name in the binary:

$ cargo asm --dev rust
[...]
Try one of those by name or a sequence number
0 "rust::main" [112]
1 "std::sys_common::backtrace::__rust_begin_short_backtrace" [55]

shows only one main function
("rust" is just the name of my package, could be any other string, sorry it's confusing)

(Side note: cargo asm --dev main 1234567 produces the same output with no indication that "1234567" is nonsense. Would be nice to error out instead.)

[pacak]

If you pass --everything do you get both sections?

[al13n321]

(Oh, and here's the --everything output, in case it's significantly different from the .s file: https://pastebin.com/nR5zhdKY )

[pacak]

--everything should be the same as .s but with syntax highlight if available and demangled names. Will take a look, not sure what's going on. Windows is strange sometimes :)

[al13n321]

Looking into it a little, I'm struggling to figure out how exactly these .seh_* pseudos are organized.

The relevant parts of the .s file appear to be (paraphrased a little), for a function "foo":

    .def foo
    .section .text,...,foo
.foo:
.Lfunc_begin1337:
.seh_proc foo
    <actual code>
    .seh_handlerdata
    .section .text,...,foo      <--- wtf?
    .seh_endproc
    .def "?dtor$foo"
"?dtor$foo":
.seh_proc "?dtor$foo"
    <some uninteresting exception handling code>
<possibly some more dtor blocks like above>
.Lfunc_end1337

So, a simple solution would be to not make find_items() ignore consecutive duplicate .section directives. Then the output will have both the function's main code and all the dtor blocks.

(I don't really know how correct this is, because I don't understand what these duplicate .section directives are even supposed to mean. E.g. maybe the second .section should be ignored not because it's a duplicate but because it's inside a .seh_proc/.seh_endproc pair?)

I'll send a PR for this later, if this sounds reasonable.

---

There are apparently lots of these dtor blocks in less trivial code. E.g. this 6-line function produced 15 dtor blocks: https://pastebin.com/UrjwgY6w . Presumably because of inlining, but still! Would be pretty annoying if they're all included in the cargo-show-asm output by default. So I would also add a hack making find_items() treat the first .seh_endproc as the end of function, instead of waiting for .Lfunc_end.

But is this different on other platforms? Do they also generate lots of duplicate code for panic unwinding depending on where the panic happened? Or is it more concise somehow? Is it included in the cargo-show-asm output too? Maybe I'll test it on Mac OS later.

EDIT: On a second look, in that example with 15 dtor blocks, their total size is still less than the body of the function, and they're kind of out of the way (at the end), so probably better to not do anything about this and print them all.

[pacak]

Do you ever want to look at contents of those dtor blocks? Displaying 15 of them is not a big deal. cargo-show-asm collapses items with identical names (but different hashes) like this:

 17 "<T as serde::de::Expected>::fmt" [7, 7, 7, 7, 7, 7, 7, 7, 16, 7, 7, 12, 7, 7, 7, 7, 12, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7]

^ there's a bunch of <T as serde::de::Expected>::fmt items, those numbers are showing their sizes in lines and you can pick which one you want to look at by passing a name + index.

Does it makes sense to do something similar for destructors?

[pacak]

seh_* is used for structural exception handling and seems to be windows specific, at least the example you have in the ticket generates nothing like that on Linux.

There's a list of supported commands here: https://sourceware.org/legacy-ml/binutils/2009-08/msg00193.html

As far as I can see problem comes from cargo-show-asm not recognizing things like
"?dtor$3@?0?_ZN4rust4main17h90585feb19c01afdE@4HA": as labels and mangling previous definition and if we start parsing them - they will automagically show up in parsed names.

Parsing code lives here:

cargo-show-asm/src/asm/statements.rs

Line 172 in 1596f47

impl<'a> Label<'a> {

[al13n321]

As far as I can see problem comes from cargo-show-asm not recognizing things like
"?dtor$3@?0?_ZN4rust4main17h90585feb19c01afdE@4HA": as labels and mangling previous definition and if we start parsing them - they will automagically show up in parsed names.

For each function there's only one pair .Lfunc_begin - .Lfunc_end, surrounding both the main body of the function and all the dtor blocks. Would it make sense to treat all the code between .Lfunc_begin and .Lfunc_end as one block of code - the code of the function? I'm guessing this is in line with the codegen's intention, and it seems more useful (I'd rather see all of the function's code at once than request the dtor blocks one by one). Then we don't have to recognize or separate out the dtor blocks (labels, seh_* directives, any of that) - they can be considered function's internal implementation details. That's how my PR interprets things.

[pacak]

Was fixed here #112