Basic support based on only on reading the names section of a wasm file.
Diff Detail
- Build Status
Buildable 4751 Build 4751: arc lint + arc unit
Event Timeline
Overall, looks good. You know things are starting to get real when you can run nm on them ;-).
lib/Object/WasmObjectFile.cpp | ||
---|---|---|
119 | This code doesn't handle truncated object files, where the file stops before Count names, or a name stops before the number of bytes it's supposed to have, or an LEB stops before its terminating byte. It could end up reading memory beyond the end of the object file. At a glance, it looks like lib/Object code in general isn't super picky about this kind of thing in general though, so I'll leave it up to you what you want to do here. | |
170 | ObjectFile's default printSymbolName implementation just calls getSymbolName. Could we implement getSymbolName instead, and drop this printSymbolName override? | |
173 | Concerning SF_Executable, that makes sense to hard-code here for now because the current patch is only parsing the current name section, which only provides names for functions. Could you mention this in a comment? Concerning SF_Global, it seems like the real global symbol names would be the import/export names, which this patch isn't decoding yet. Name-section names are a different kind of thing; at first glance, it does seem useful to include them in nm output, however they're not visible to other modules. So perhaps they should be non-global. | |
194 | Symb.d.a is effectively holding a function-index-space value here. That seems fine for now, though it's worth thinking about whether we eventually want to be printing table indices instead (although that raises other questions, since not all functions will be in the table, and functions could theoretically appear in the table multiple times.) Could you add some comments here mentioning these considerations? |
Abandoning in favor of larger change that handles imports and exports too: https://reviews.llvm.org/D31099
This code doesn't handle truncated object files, where the file stops before Count names, or a name stops before the number of bytes it's supposed to have, or an LEB stops before its terminating byte. It could end up reading memory beyond the end of the object file. At a glance, it looks like lib/Object code in general isn't super picky about this kind of thing in general though, so I'll leave it up to you what you want to do here.