Skip to content
This repository has been archived by the owner on Dec 19, 2022. It is now read-only.

Save indexes of entries of certain sections #17

Closed
Luukdegram opened this issue Oct 8, 2021 · 3 comments
Closed

Save indexes of entries of certain sections #17

Luukdegram opened this issue Oct 8, 2021 · 3 comments

Comments

@Luukdegram
Copy link
Owner

Luukdegram commented Oct 8, 2021

The symbols inside the symbol table have a field index.
This index represents the index of the object itself within a section. This means that if we have 2 imported functions, and 2 defined functions, the max function index is 3. Currently, we only save imports within the import section. This means that for a symbol with index 2, we would get an out-of-bounds panic. To combat this, we must save an index of entries inside sections (such as a function section) that is not only increased by the section entries themselves, but also by imports.
Then, during the parsing of the symbol table, we can find the corresponding function of a symbol by matching the index.

This would need to be done for:

  • functions
  • memory
  • globals
  • tables

Another possibility is to count imports for that symbol type, and subtract that amount from the symbol index. This may be simpler, but the first option may provide us with more information during other processes. Time will tell what the final decision will be based on the usefulness of saving the index on the section entry itself.

@Luukdegram
Copy link
Owner Author

After further investigation, this 'assumption' may not be correct.
Rather than going out of bounds, we should verify the symbol kind, and then retrieve the correct object based on that.

@Luukdegram
Copy link
Owner Author

As commented above, my assumption was wrong.
Incorrect indexes was due to reading incorrect objects.

@Luukdegram
Copy link
Owner Author

Finally fully verified how imports work.
Undefined symbol's index points to an import as we know. However, the index is not the index of the total list of imports but is type-specific. Meaning that per type, you essentially have a list to index into.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant