Ordering of sections in wasm_encoder

[thesuhas]

Hi,
So I'm writing Orca a Library for WASM transportations for the Component Model.
I'm facing an issue where on parsing a given wasm file, the ordering of two sections seems to defer when I write it to a new file.
This is the ordering that I get on encoding:

(alias core export 0 "memory" (core memory (;0;)))
  (core instance (;0;) (instantiate 0))

This is what the original file is:

core instance (;0;) (instantiate 0))
  (alias core export 0 "memory" (core memory (;0;)))

And I've only noticed this with the alias section in Components. I tried playing around when I define the Alias Section in a Component and this didn't seem to change the ordering.

I also see that both of these are semantically different where wasm-tools validate throws an exception on the encoded wasm file I generate (where alias is before instance).

I was wondering if some light could be shed on this and if we can define the ordering of sections in wasm_encoder

[alexcrichton]

In theory wasm-encoder shouldn't reorder anything and is low-level enough that it's just respecting whatever you feed to it in whatever order that happens to be. Can you describe in a bit more detail how the valid file is generated vs the erroneous file? This could also possibly be a bug in the binary-to-text function of wasmprinter too.

[thesuhas]

For more context, this is the file:

(component
  (core module (;0;)
    (type (;0;) (func))
    (type (;1;) (func (result i32)))
    (type (;2;) (func (param i32 i32)))
    (type (;3;) (func (param i32 i32 i32 i32) (result i32)))
    (type (;4;) (func (param i32 i32 i32 i32 i32 i32 i32 i32)))
    (type (;5;) (func (param i32 i32) (result i32)))
    (func (;0;) (type 5) (param i32 i32) (result i32)
      local.get 0
      local.get 1
      i32.add
    )
    (func (;1;) (type 0)
      i32.const 1
      i32.const 2
      call 1
      drop
      drop
    )
    (memory (;0;) 1)
    (export "add" (func 1))
    (export "memory" (memory 0))
  )
  (core instance (;0;) (instantiate 0))
  (alias core export 0 "memory" (core memory (;0;)))
  (@producers
    (processed-by "wit-component" "0.207.0")
  )
)

It's a simple component that just adds two numbers.
All we do is use wasmparser to parse this file and create an intermediate representation. Then we encode it using wasm_encoder and write it to a new wasm file.

Does the order in which we encode these sections in the wasm_encoder matter?

This results in the alias section being present before the core instance in the new file.

[alexcrichton]

The order of encoding sections definitely matters yeah, so you'll have to encode the core instance section before the alias section. The work in #1656 may be of interest here perhaps and might help your use case?