Some way to distinguish WLA symbol maps from other symbol maps. #612
Replies: 5 comments 2 replies
-
|
Haven't looked what would be the best solution, how about under [information] something like "linker = wlalink" and "linkerversion = vx.y"? I'll come back to this tomorrow evening and implement something like that... |
Beta Was this translation helpful? Give feedback.
-
|
Looking at this issue. I can see WLALINK already writes a commet like header to the symbol file that contains the string "wlalink" - that could be used to identify that the symbol file was written by WLALINK. But I'll add "format wlasymbolfile" to [information] if that helps... |
Beta Was this translation helpful? Give feedback.
-
|
My main concern about the comment is that the comment could be altered if it's made by a different linker that supports the same symbol map or was stripped by another system to save a few bytes on the hard disk. |
Beta Was this translation helpful? Give feedback.
-
|
Or actually I know nothing of other symbol files so I'll follow your advice here and add "wlasymbol true" under [information]... |
Beta Was this translation helpful? Give feedback.
-
|
Ok, check out the latest sources |
Beta Was this translation helpful? Give feedback.
-
|
@Pokeman2003 Please let me know if the latest sources solve your issue. I'm planning on releasing the next release quite soon so having this fixed before the release is quite important. :) |
Beta Was this translation helpful? Give feedback.
-
|
As far as I can tell, this fixes my "issue!" Thank you for this implementation. |
Beta Was this translation helpful? Give feedback.
-
I quite like this assembler, but the Gearsystem is not compatible with its symbol maps. The developer seems interested in adding support for the symbol maps that WLA-Linker generates, but I've known for a bit that there's really no way to distinguish a WLA symbol map from any other relatively similar symbol map. Most notably, the
[source files v2]and[definitions]sections seem to really trip up Gearsystem's parser for being so similar to another symbol map's format. It stands to reason then that any parsers which DO support multiple formats may have trouble figuring out which format you're trying to feed them.I think this confusion for multi-format parsers could easily be solved with some distinguishing factor within the symbol maps that could be immediately parsed and recognized as "yup, that's WLA," regardless of who generated the symbol map(so no relying on the
this file was created with wlalinkcomment generated at the top.) I don't really have a fantastic solution, but I've got a couple of spitball ideas. Perhaps linkers could generate an intentionally blank section that's just called[wlasymbol]? Or maybe something can fall under[information], perhaps a line that just sayswlasymbol true?Beta Was this translation helpful? Give feedback.
All reactions