[PATCH] D148042: [MSP430] Get the DWARF pointer size from MCAsmInfo instead of DataLayout.
Anton Korobeynikov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Apr 18 14:32:37 PDT 2023
asl added a subscriber: probinson.
asl added a comment.
@dblaikie as far as I can see, there are several interconnected issues here.
First of all, ELF could be 32-bit or 64-bit (EI_CLASS field in ELF header), there are no 16-bit ELF files defined around and I do not think it's a good idea to invent something new here. Next, LLDB indeed assumes that pointer size coincides with ELF class and I would not consider it as a bug :) And it seems there is no way to specify that inside ELF file that ELF32 file could contain 16-bit pointers.
We are seeing a precedent of msp430-gcc to generate 32-bit pointers inside ELF32 file for MSP430 architecture and eventually we need to be able to mix-and-match linking with such objects as they could be in e.g. CRT, etc.
So, it seems we need a way to distinguish between "platform address size" that it used for code generation, optimizations, etc. and "address size used for DWARF emission" (both for data and code!). Currently LLVM assumes that they are the same and the patch allows a platform to override it. Even more, MSP430X extention uses 20-bit pointers, so we'd end with something similar here one way or another.
It seems currently they things a bit messy in how we're emitting DWARF data (see https://discourse.llvm.org/t/what-is-a-codepointersize-and-how-does-it-relate-to-dwarf/64825 for example)
If you're overseeing better solution of the problem, then it would be good to hear how :)
I'm also tagging @probinson for some insights
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D148042/new/
https://reviews.llvm.org/D148042
More information about the llvm-commits
mailing list