This adds the .importsym directive which lets you import a pre-existing symfile. This is pretty useful when you have a base symfile for a game and you want to merge all your new labels into it.
Currently this enforces No$gba semantics where each address must be exactly 8 characters. I'm not sure if sym2 format symfiles allow for different lengths; if so, the restriction could probably be removed.
Also, this doesn't remove or change any data in the output symfile that's overwritten by armips. E.g., you have a memory region that's defined as a data pool and you write a function in there instead, the original data pool definition will be copied to the output symfile as-is (in addition to any new labels you placed in that region). I don't think this is a big problem, though.
.importsym SymFile
Imports all symbols from the existing symfile specified by SymFile. For any symbols in SymFile not starting with ., @ or @@, a global label will be created, which can be used like any other label. Regardless of prefix, all symbols and directives in SymFile are also written to the main output symfile for this run of armips, if symfile writing is enabled. This directive terminates the scope for local labels and equs.
This adds the
.importsymdirective which lets you import a pre-existing symfile. This is pretty useful when you have a base symfile for a game and you want to merge all your new labels into it.Currently this enforces No$gba semantics where each address must be exactly 8 characters. I'm not sure if
sym2format symfiles allow for different lengths; if so, the restriction could probably be removed.Also, this doesn't remove or change any data in the output symfile that's overwritten by armips. E.g., you have a memory region that's defined as a data pool and you write a function in there instead, the original data pool definition will be copied to the output symfile as-is (in addition to any new labels you placed in that region). I don't think this is a big problem, though.