rustwasm / twiggy Goto Github PK

#84 added a summary to the output of the 'garbage' sub-command, which looks like this:

 Bytes │ Size % │ Garbage Item
───────┼────────┼──────────────────────
    11 ┊  5.58% ┊ unusedAddThreeNumbers
     8 ┊  4.06% ┊ unusedAddOne
   ... ┊    ... ┊ ... and 7 more
    43 ┊ 21.83% ┊ Σ

I think this is a really fantastic idea. Should we add a similar feature to other sub-commands as well? I think the 'top' and 'diff' would be a good start, although I am less sure about the others.

It could be neat to do something similar for the paths command, like this:

               Shallow Bytes │ Shallow %          │ Retaining Paths
───────────────┼───────────┼────────────────────────────
            44 ┊    30.56% ┊ "function names" subsection
             7 ┊     4.86% ┊ export "awoo"
               ┊           ┊   ↳ func[4]
               ┊           ┊       ↳ type[0]
               ┊           ┊       ↳ awoo
               ┊           ┊            ↳ ... and 6 more

(That's imagining what this file might look like)

To Do:

• diff
• garbage
• monos
• paths
• top

Hi,
It seems to me that this tool is not capable of producing the output when the .wasm file size is bigger(even 5 MB ). However, it works well when I use a small size .wasm file.
Do you have any plan to fix this issue and release a new version of twiggy.exe.

instead of JOB=wasm ./ci/script.sh.

• in CI
• publishing to npm

I guess it feels good enough for me now, but wondering if anyone else has any opinions.

:(

Building off of some discussion in #120:

It might be nice to add a way to name specific generic functions that we would like to display, so that we could narrow down our test expectations a little.

It can be annoying to specify the whole item name, including the hash at the end. We should support doing just my_crate::.* etc.

Probably a table similar to twiggy top but sorted by absolute size of delta.

Using this wasm file executing twiggy dominators -r 1 still seems to print all the rows! The --help page though indicates that -r is the maximum number of rows to display

$ svelte dominators $FUNCTION should display just the given function's subtree in the dominator tree.

• I want to be able to investigate monomorphizations of generic functions
  • list generic functions by the total code size of all of their monomorphizations
  • how many times was this generic function monomorphized?
  • how much space would I save if I switched to dynamic dispatch and trait objects for this generic function instead of monomorphization?

We can implement this by inspecting the demangled symbol for an IR node and extracting the generic function that it is a monomorphization of (if any) and storing that in the IR nodes as well. Then we would have a new analysis that groups IR nodes by the genric function they're monomorphizations of, and sort by most monomorphizations. Finally, we would expose it on the CLI as

$ svelte monos ...

Hello,

I'm trying to use twiggy 0.2.0 with mono's wasm port and hitting this crash on OSX:

tijuca:wasm rokumper$ RUST_BACKTRACE=1 twiggy top debug/mono.wasm
thread 'main' panicked at 'assertion failed: index < u32::MAX as usize', /Users/kumpera/.cargo/registry/src/github.com-1ecc6299db9ec823/twiggy-ir-0.2.0/./ir.rs:414:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: twiggy_ir::Id::entry
   7: twiggy_parser::wasm::<impl twiggy_parser::Parse<'a> for parity_wasm::elements::section::ElementSection>::parse_edges
   8: twiggy_parser::wasm::<impl twiggy_parser::Parse<'a> for parity_wasm::elements::module::Module>::parse_edges
   9: twiggy_parser::parse_wasm
  10: twiggy_parser::read_and_parse
  11: twiggy::main
  12: std::rt::lang_start::{{closure}}
  13: std::panicking::try::do_call
  14: __rust_maybe_catch_panic
  15: std::rt::lang_start_internal
  16: main

To reproduce it. Download this file: https://jenkins.mono-project.com/job/test-mono-mainline-wasm/926/label=ubuntu-1804-amd64/Azure/processDownloadRequest/926/ubuntu-1804-amd64/sdks/wasm/mono-wasm-24c1f2a40c1.zip

Then run twiggy: twiggy top debug/mono.wasm

Ok, clearly this wasm's size has a lot going on in the data section:

~/twiggy
$ twiggy top -n 10 ~/gutenberg-parser-rs/bindings/wasm/gutenberg_post_parser.debug.wasm 
 Shallow Bytes │ Shallow % │ Item
───────────────┼───────────┼───────────────────────────────────────────────────────────────────────────────────
          6285 ┊     6.49% ┊ data[4]
          3653 ┊     3.77% ┊ gutenberg_post_parser::parser::block::h482c2450268e1452
          3485 ┊     3.60% ┊ <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter::h16c80f212f4e48bd
          2726 ┊     2.82% ┊ "function names" subsection
          2593 ┊     2.68% ┊ data[2807]
          1900 ┊     1.96% ┊ data[5]
          1796 ┊     1.86% ┊ data[2804]
          1771 ┊     1.83% ┊ data[0]
          1749 ┊     1.81% ┊ data[2749]
          1486 ┊     1.54% ┊ data[38]

Which functions are using this data?

~/twiggy
$ twiggy paths ~/gutenberg-parser-rs/bindings/wasm/gutenberg_post_parser.debug.wasm 'data[4]' 'data[2807]' 'data[5]' 'data[2804]' 'data[0]' 'data[2749]' 'data[38]'
 Shallow Bytes │ Shallow % │ Retaining Paths
───────────────┼───────────┼────────────────
          1771 ┊     1.83% ┊ data[0]
          6285 ┊     6.49% ┊ data[4]
          1900 ┊     1.96% ┊ data[5]
          1486 ┊     1.54% ┊ data[38]
          1749 ┊     1.81% ┊ data[2749]
          1796 ┊     1.86% ┊ data[2804]
          2593 ┊     2.68% ┊ data[2807]

No edges to the data segments found. I don't believe that is accurate.

💡 Feature Description

We should render the human readable type along with which entry in the types section it is.

The change needs to happen in the parse_items trait method impl for TypeSection: https://github.com/rustwasm/twiggy/blob/master/parser/wasm_parse/mod.rs#L248-L249

💻 Example Usage

Right now we get output like:

              7 ┊      0.00% ┊ type[4]
              7 ┊      0.00% ┊ type[11]
              6 ┊      0.00% ┊ type[3]

but instead we should have output like:

              7 ┊      0.00% ┊ type[4]: (i32,  i32) -> i32
              7 ┊      0.00% ┊ type[11]: (i32) -> nil
              6 ┊      0.00% ┊ type[3]: (f64) -> f64

Maybe a good next issue to tackle for you, @data-pup

The new iter_causes method does the skip(1) dance for us and now causes is deprecated too.

warning: use of deprecated item 'failure::Fail::causes': please use the 'iter_causes()' method instead
  --> twiggy/./twiggy.rs:22:20
   |
22 |         for c in e.causes().skip(1) {
   |                    ^^^^^^
   |
   = note: #[warn(deprecated)] on by default

Hi! As a Windows user I was pretty confused about all those twiggy tests failing locally on my laptop... Until I figured it out that it's only about different line endings in expected output. I fixed that for now in #116 but think it would be generally good to also continuously run the build and tests on Windows via AppVeyor integration. I have experience with AppVeyor and would volunteer to care about that :)

🐛 Bug Description

twiggy fails to detect wasm files when they don't have a .wasm extension.

twiggy version: twiggy-opt 0.3.0

🌍 Test Case

Any file works, for example this one (5MB).

👟 Steps to Reproduce

$ twiggy top test_case
 Shallow Bytes │ Shallow % │ Item
───────────────┼───────────┼──────────────────
             0 ┊     0.00% ┊ Σ [0 Total Rows]
$ mv test_case test_case.wasm
$ twitty top test_case.wasm
<expected output>

😲 Actual Behavior

File is not detected as wasm.

🤔 Expected Behavior

The file should be detected as wasm by looking at its contents, not by using the filename extension.

Hi,

I wanted to add twiggy to the list of linters at awesome-static-analysis, but I was unsure about the license of the code. Can we add a license to the project? 😃

We should be able to emit an HTML file containing:

• the whole serialized IR graph (not just one analysis on it) as JSON
• a base 64 encoded .wasm blob, that contains a Yew app that deserializes the IR graph and then interactively runs any analysis on it that you might choose.

This HTML file would be able to be sent easily as an email attachment or uploaded to a bug tracker, etc. Since it is just a single HTML file, and you wouldn't need to wrangle an HTML file and a JS file and a wasm file and ... and keep their relative positions on the filesystem correct.

This would print code and data that is not transitively referenced by any exports / public functions. Since linkers and compilers tend to remove dead code, this is more likely to find bugs in our IR graph, but that is also a useful thing ;)

Currently twiggy does an excellent job at profiling things like function sizes and such, but its accounting doesn't always add up to 100% of the bytes in a file. For example on WebAssembly there's an 8 byte header on all wasm files unaccounted for, section ids and the leb128 to say how big a section is is also not accounted for.

It'd be neat if internally we could refactor this to perhaps have overlapping nodes in a file. For example I'd say that the code section (leading indicator byte and leb128 size and all) is 10 bytes large. Two functions inside there would then be, perhaps, 5 and 3 bytes large. That means that the code section alone is 2 bytes large, and 8/10 other bytes are accounted for in elements of the section.

I'm not sure that the internals of twiggy though are quite ready for this sort of nesting relationship, but it'd be neat to account for 100% of bytes

Currently, we have a fairly thorough test bench. It would be nice however, if we also had some benchmarks for the different sub-commands, so that we could reason about how certain changes affect performance.

I'm trying to install twiggy with cargo, but on my Windows 10 I'm encountering the following build error:

error: failed to run custom build command for `twiggy-opt v0.1.0`
process didn't exit successfully: `C:\Users\D071863\AppData\Local\Temp\cargo-installUGK4Ht\release\build\twiggy-opt-8f09be37635e03b4\build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-changed=./definitions.js

--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }', libcore\result.rs:945:5
stack backtrace:
   0: std::sys::windows::backtrace::unwind_backtrace
             at C:\projects\rust\src\libstd\sys\windows\backtrace\mod.rs:65
   1: std::sys_common::backtrace::_print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:71
   2: std::sys_common::backtrace::print
             at C:\projects\rust\src\libstd\sys_common\backtrace.rs:59
   3: std::panicking::default_hook::{{closure}}
             at C:\projects\rust\src\libstd\panicking.rs:211
   4: std::panicking::default_hook
             at C:\projects\rust\src\libstd\panicking.rs:227
   5: std::panicking::rust_panic_with_hook
             at C:\projects\rust\src\libstd\panicking.rs:463
   6: std::panicking::begin_panic_fmt
             at C:\projects\rust\src\libstd\panicking.rs:350
   7: std::panicking::rust_begin_panic
             at C:\projects\rust\src\libstd\panicking.rs:328
   8: core::panicking::panic_fmt
             at C:\projects\rust\src\libcore\panicking.rs:71
   9: core::result::unwrap_failed
  10: core::result::unwrap_failed
  11: core::result::unwrap_failed
  12: <alloc::raw_vec::RawVec<T, A>>::reserve
  13: std::rt::lang_start_internal::{{closure}}
             at C:\projects\rust\src\libstd\rt.rs:59
  14: std::panicking::try::do_call<closure,i32>
             at C:\projects\rust\src\libstd\panicking.rs:310
  15: panic_unwind::__rust_maybe_catch_panic
             at C:\projects\rust\src\libpanic_unwind\lib.rs:105
  16: std::panicking::try
             at C:\projects\rust\src\libstd\panicking.rs:289
  17: std::panic::catch_unwind
             at C:\projects\rust\src\libstd\panic.rs:374
  18: std::rt::lang_start_internal
             at C:\projects\rust\src\libstd\rt.rs:58
  19: main
  20: invoke_main
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:64
  21: __scrt_common_main_seh
             at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:253
  22: BaseThreadInitThunk
  23: RtlUserThreadStart

warning: build failed, waiting for other jobs to finish...
error: failed to compile `twiggy v0.1.0`, intermediate artifacts can be found at `C:\Users\D071863\AppData\Local\Temp\cargo-installUGK4Ht`

Caused by:
  build failed

Any ideas what's going on here?

Tracking issue for adding ELF compatibility to twiggy.

#4 lists some binary formats that we would like to add compatibility for, including ELF, Mach-O, and PE/COFF. These might be somewhat involved tasks, so this issue will specifically track work/discussion related to adding ELF compatibility.

As mentioned in that issue, we can use goblin to parse IR nodes.

gimli is a library for consuming the DWARF debugging format, which may come in handy. This is a good introduction link to DWARF.

The object crate might also be useful for this, it is a "unified interface for parsing object file formats."

We shouldn't require cargo install to get twiggy -- we should have pre-built binaries that we distribute for releases. This requires some CI configuring and all that.

svelte needs a team of people who can review each other's pull requests, and make consensus-based decisions together about its future.

Anyone who has made two meaningful contributions to svelte should seriously consider joining the team!

Drop a comment here if you are interested in joining.

• maximum depth in dominator tree
• maximum number of rows to include in output, regardless of depth

Each of these involves new fields on the Dominator struct in ./opt/opt.rs.

The DominatorTree struct in analyze/analyze.rs should make and hold a copy of the opt::Dominators options.

Then, the impl traits::Emit for DominatorTree should consult the new options and modify its output appropriately.

Hi,
Is there any way to build it and get the twiggy.exe ?

Maybe named

$ svelte summarize

?

Bonus points if we selectively summarize some items within certain crates/namespaces, but leave others un-summarized. For example, collapse all of std into one row in a result table, but have all the items in my_crate un-summarized.

Right now it is --sort-by (shallow|retained) with default to shallow. But that means that one would never do --sort-by shallow, so this option only exists to enable sorting by retained size. So it should just be -r/--retained instead of the current behavior.

This mostly involves changing the option parsing in opt/opt.rs.

Function exports refer functions via global function index. And global index space consist of all imported items concatenated with all defined items in the module.

Here is the code that uses global index to index into function section.
https://github.com/fitzgen/svelte/blob/5e1bcd3404583c05d8427e6900b967a52ec098e9/parser/wasm.rs#L400-L404

This code is incorrect because it uses to a global index to index into function section (which only contains defined functions).

For example:

$ svelte paths tests/fixtures/mappings.wasm compute_column_spans
 Shallow Bytes │ Shallow % │ Retaining Paths
───────────────┼───────────┼─────────────────────────────────────────
           299 ┊     0.66% ┊ compute_column_spans
               ┊           ┊   ⬑ func[5]
               ┊           ┊       ⬑ export "by_generated_location"

Using twiggy-opt 0.3.0 on a wasm file as twiggy dominators -d 1 foo.wasm (trying to get all the roots of large sizes) prints out a lot of entries as func [xx]. I found this somewhat confusing because the wasm binary had the function names subsection, but it turns out that I needed to path -d 2 because it looks like in the dominator tree there's a function node which dominates the node with the function's name. Using twiggy dominators -d 2 did indeed print out the function names.

Would it be possible to have the function names come up at depth 1 as well?

The readme says it exists, but it doesn't yet.

Similar to #13 but for the svelte paths subcommand.

Should be able to control how deep we will print paths, and how many total paths we will print.

Check out opt/opt.rs for options parsing and analyze/analyze.rs for adjusting behavior based on those options.

Using this wasm file you get:

$ twiggy dominators -d 1 foo.wasm
 Retained Bytes │ Retained % │ Dominator Tree
────────────────┼────────────┼────────────────────────────────────────
          84355 ┊     39.68% ┊ export "format"
          16045 ┊      7.55% ┊ "function names" subsection
          10997 ┊      5.17% ┊ table[0]
           3465 ┊      1.63% ┊ func[18]
           1836 ┊      0.86% ┊ func[86]
           1199 ┊      0.56% ┊ func[26]
           1059 ┊      0.50% ┊ func[104]
            965 ┊      0.45% ┊ func[2]
            710 ┊      0.33% ┊ func[96]
            340 ┊      0.16% ┊ func[149]
            327 ┊      0.15% ┊ func[150]
            261 ┊      0.12% ┊ func[158]
            140 ┊      0.07% ┊ func[52]
            140 ┊      0.07% ┊ func[74]
            138 ┊      0.06% ┊ func[155]
            137 ┊      0.06% ┊ func[50]
            125 ┊      0.06% ┊ func[92]
            117 ┊      0.06% ┊ func[119]
            106 ┊      0.05% ┊ func[14]
             87 ┊      0.04% ┊ func[108]
             75 ┊      0.04% ┊ func[146]
             70 ┊      0.03% ┊ func[201]
             63 ┊      0.03% ┊ export "__wbindgen_malloc"
             56 ┊      0.03% ┊ func[199]
             53 ┊      0.02% ┊ func[93]
             42 ┊      0.02% ┊ export "__wbindgen_global_argument_ptr"
             34 ┊      0.02% ┊ export "__wbindgen_free"
             28 ┊      0.01% ┊ export "__indirect_function_table"
             22 ┊      0.01% ┊ export "__heap_base"
             21 ┊      0.01% ┊ export "__data_end"
             12 ┊      0.01% ┊ func[87]
             11 ┊      0.01% ┊ export "memory"
              8 ┊      0.00% ┊ type[10]
              8 ┊      0.00% ┊ global[0]
              7 ┊      0.00% ┊ type[4]
              7 ┊      0.00% ┊ type[11]
              6 ┊      0.00% ┊ type[3]
              6 ┊      0.00% ┊ type[7]
              5 ┊      0.00% ┊ type[5]
              5 ┊      0.00% ┊ type[8]
              5 ┊      0.00% ┊ type[14]
              4 ┊      0.00% ┊ type[0]
              4 ┊      0.00% ┊ type[1]
              3 ┊      0.00% ┊ type[6]

The file itself is 212k bytes, but the numbers on the left don't seem to add up to that. Is some data left out by accident perhaps?

Currently, we are working on adding logic to display summaries of truncated rows for different sub-commands in #88. This is nice because the number of items is displayed, but it would be nice if we had an --all option to simply display all items, instead of something like --max-items $BIG_NUMBER.

The top sub-command would be a nice place to start, but this should eventually be done for all of the subcommands.

To Do:

• diff
• dominators
• garbage
• monos
• paths
• top

💡 Feature Description

When twiggy garbage reports false positives, they are often data segments. The reason is that code accessing data segments can do arbitrary computations to conjure up a data segment's linear memory address and we only recognize a very limited pattern of (load (const $addr)).^*

To avoid reporting so many false positives, by default we should hide individual unused data segments, and instead summarize them in a single row. If the user provides the --show-data-segments flag (open to suggestions on a better flag name!) then we can show all the potentially-false-positive data segments like our current behavior.

The potentially-false-positive data segments should not be included in the Σ row. It should have its own, distinct summary row.

^* While we can certainly improve our ability to recognize uses of addresses, we can't find everything without literally executing the whole program (and even that might not find every edge if it doesn't encounter every possible input state...).

💻 Example Usage

Default.

$ twiggy garbage input.wasm
 Bytes │ Size % │ Garbage Item
───────┼────────┼───────────────────
   404 ┊  1.02% ┊ code[42]
...
   802 ┊  1.56% ┊ ... and 25 more
  2294 ┊  4.48% ┊ Σ [35 Total Rows]
   596 ┊  1.16% ┊ 14 potential false positive data segments

With --show-data-segments. Now the data segments should be included in the Σ row.

$ twiggy garbage input.wasm --show-data-segments
 Bytes │ Size % │ Garbage Item
───────┼────────┼───────────────────
   404 ┊  1.02% ┊ code[42]
   209 ┊  0.41% ┊ data[25]
   122 ┊  0.24% ┊ data[0]
   113 ┊  0.22% ┊ data[16]
   102 ┊  0.20% ┊ data[1]
    77 ┊  0.15% ┊ data[28]
    77 ┊  0.15% ┊ data[34]
    73 ┊  0.14% ┊ data[12]
    63 ┊  0.12% ┊ data[13]
    60 ┊  0.12% ┊ data[15]
   802 ┊  1.56% ┊ ... and 25 more
  2294 ┊  4.48% ┊ Σ [35 Total Rows]

🙌 How to fix this

• Add new flag to definition of Garbage options struct: https://github.com/rustwasm/twiggy/blob/master/opt/definitions.rs

• Code for twiggy garbage analysis is in this module: https://github.com/rustwasm/twiggy/blob/master/analyze/analyses/garbage.rs

This would do cargo build and then run twiggy target/.. on the just-built binary.

We would need to pass through whatever extra flags to cargo.

A little bit tricky to figure out the path for the just-built binary. Maybe a cargo knowledgeable person can out.

Similar to wasm-bindgen's mdbook set up

Once #51 lands, we should add functionality that allows the subtree argument given to twiggy dominators to be a regex.

Question: This might also require implementing the ability to print multiple subtrees, is that correct? cc: @fitzgen

We can use goblin to parse IR nodes, but parsing IR edges might be a little trickier. The DW_TAG_call_site ^{0 1} attribute, if present in the DWARF debugging information, could help. Otherwise, we'll need to disassemble instructions.

• ELF
• Mach-O
• PE/COFF

Again, the readme says it exist, but it doesn't yet

Hey, I tried to use "twiggy top" but it asks me about parameters. It would be nice to have default parameters, especially that in readme it says "use twiggy top" but don't mention parameters.

Maybe just root all the functions that could possible be called indirectly.

Right now we support:

• human readable text
• JSON

but it would be great to also emit:

• CSV
• Graphviz Dot

See ./traits/traits.rs and grep for impl Emit for

The twiggy binary should enable them all by default. The wasm API should enable only the JSON output format.

Try this out:
svelte dominators wee_alloc.wasm -o output.txt

Also causes an error if output.txt is not present. It must create the file if the file is not present.
And also update options info for help.

It will actually tell us which functions are using which data. The parity_wasm crate also parses the relocations section, so it shouldn't be too hard to add support for.

If we did this, and our results are noticably better when we have relocations, then we should also document how to build rust to wasm and preserve relocations.