[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