jakehehrlich added a comment.
I think I know the format that I'd like *roughly*. I haven't worked out how to
handle COMDAT and section groups yet. Roland seems to think that COMDAT and
section groups will be an issue but I'm working out the details with him to
make sure I understand it. I'll get back to you soon.
Version: 1.0
Arch: AArch64
Symbols:
- Name: foo
Type: Function
Weak: true
- Name: bar
Type: Function
Defined: false
- Name: baz
Type: Object
Size: 256
Alignment: 32
Only Arch is used other details from your header can be inferred as defaults
but are not needed here. I think binding is not needed beyond Weak vs. Not
Weak. I spoke with Roland about this and he pointed out STB_GNU_UNIQUE. This
would motivate allowing Global, Weak, and GNU_UNIQUE as valid bindings. The
only cases for viability that we care are protected and default. Internal and
hidden will never appear in the public interface. We can treat protected and
default as the same as they just mean that the symbol will appear in the public
interface and their difference is related to how the linker resolves symbols
relative to module itself not other external modules.
We don't have to worry about symbol version (and the TextAPI types don't
support that yet either) but Warnings are another case to think about. Each
symbol can have a warning string associated with it. This will be one of the
last features (before symbol versions but after almost everyhing else) that
support is added for in llvm-elfabi so I think we can ignore it here for now.
One thing we forgot to add in llvm-elfabi that we now know we need to add is
Alignment. Alignment can be computed from the section and the offset within the
section. This is the one bit of information that comes from the section itself
and not the symbol table.
Absolute symbols probably aren't needed but if we ever need them they're easy
enough to add via a new symbol type.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D60974/new/
https://reviews.llvm.org/D60974
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
