wzprof icon indicating copy to clipboard operation
wzprof copied to clipboard

nothing much from zig

Open codefromthecrypt opened this issue 2 years ago • 2 comments

I can compile this with zig cc --target=wasm32-wasi -o math.wasm math.c, and run it with wzprof -sample 1 -memprofile /tmp/profile math.wasm and end up an image like this on go tool pprof -http :4000 /tmp/profile:

Screenshot 2023-05-18 at 09 08 45
#include <stdio.h>

int main(int argc, char** argv)
{
  fprintf(stderr, "%d\n", 1+2);
}

Ironically, if I do the same in zig build-exe math.zig -target wasm32-wasi, I don't get anything.

const std = @import("std");

pub fn main() !void {
    std.debug.print("{}\n", .{1 + 2});
}
$ wasm-tools objdump math.wasm
  types                                  |        0xa -       0x4b |        65 bytes | 11 count
  imports                                |       0x4d -       0x93 |        70 bytes | 2 count
  functions                              |       0x95 -       0xe5 |        80 bytes | 79 count
  memories                               |       0xe7 -       0xea |         3 bytes | 1 count
  globals                                |       0xec -       0xf5 |         9 bytes | 1 count
  exports                                |       0xf7 -      0x10a |        19 bytes | 2 count
  code                                   |      0x10e -     0xa50f |     41985 bytes | 79 count
  data                                   |     0xa512 -     0xaac0 |      1454 bytes | 1 count
  custom ".debug_info"                   |     0xaacf -     0xdfa8 |     13529 bytes | 1 count
  custom ".debug_pubtypes"               |     0xdfbb -     0xe8b5 |      2298 bytes | 1 count
  custom ".debug_loc"                    |     0xe8c3 -     0xecf4 |      1073 bytes | 1 count
  custom ".debug_ranges"                 |     0xed05 -     0xf07d |       888 bytes | 1 count
  custom ".debug_abbrev"                 |     0xf08e -     0xf2d6 |       584 bytes | 1 count
  custom ".debug_line"                   |     0xf2e5 -    0x11e9d |     11192 bytes | 1 count
  custom ".debug_str"                    |    0x11eab -    0x14b7c |     11473 bytes | 1 count
  custom ".debug_pubnames"               |    0x14b8f -    0x15f57 |      5064 bytes | 1 count
  custom "name"                          |    0x15f5f -    0x16ed1 |      3954 bytes | 1 count
  custom "producers"                     |    0x16edd -    0x16eed |        16 bytes | 1 count

Let me know if you have any ideas on why!

codefromthecrypt avatar May 18 '23 07:05 codefromthecrypt

Two possibilities I can think of:

  • the zig compiler erases all dynamic memory allocations in this example program, so there is nothing to trace
  • zig uses a memory allocator that wzprof does not recognize yet and we need to add support for it in https://github.com/stealthrocket/wzprof/blob/main/mem.go#L179-L200

achille-roussel avatar May 18 '23 23:05 achille-roussel

I suppose yeah it isn't using the typical malloc/free stuff

$ wasm2wat math.wasm|grep mem.
    call $memset
      call $mem.copy__anon_2526
            call $mem.readIntNative__anon_2363
    call $memset
    call $mem.set__anon_2390
  (func $mem.readIntNative__anon_2363 (type 5) (param i32) (result i32)
  (func $mem.set__anon_2390 (type 9) (param i32 i32 i32)
  (func $mem.copy__anon_2526 (type 6) (param i32 i32 i32 i32)
    call $mem.span__anon_2680
  (func $mem.span__anon_2680 (type 9) (param i32 i32 i32)
    call $mem.len__anon_2706
  (func $mem.len__anon_2706 (type 8) (param i32 i32) (result i32)
    call $mem.copy__anon_2526
    call $memset
    call $mem.set__anon_2390
  (func $memset (type 7) (param i32 i32 i32) (result i32)
  (memory (;0;) 17)
  (export "memory" (memory 0))

codefromthecrypt avatar May 19 '23 04:05 codefromthecrypt