[PATCH] D145626: [WebAssembly] Support debug info for TLS + global in PIC mode

Heejin Ahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 10 18:49:43 PST 2023


aheejin added a comment.

In D145626#4185463 <https://reviews.llvm.org/D145626#4185463>, @dschuff wrote:

> We could test explicitly for relocation information using llvm-readobj (many MC tests do this). I guess for the static linking cases we could assert that there's a relocation against `__stack_pointer` and in the split dwarf case we could check that there are no relocations. Not sure whether that would be worth it though.

I guess you mean not `__stack_pointer` but `__tls_base` and `__memory_base`, right, This CL doesn't change anything related to `__stack_pointer` handling. (It refactors the code that handles it, but NFC on that part.)

Yes, I can do that, but AFAIK `llvm-readobj` doesn't provide any specific info on which global indices contain which reloc. All I can test is that in non-split objects there are relocations referring to `__tls_base`/`__memory_base` in `.debug_info` section, and there are no relocations in `dwo` files. I guess the latter should be ensured, like, by definition of split DWARF though.

In D145626#4185501 <https://reviews.llvm.org/D145626#4185501>, @dschuff wrote:

> One other question about the test. Did you generate it from a C file?

I originally used a C file, but edited the generated `.ll` file in several places. Also I removed unrelated debug info a lot; for example, we don't need any line debug info / local variable debug info in this test so I removed all of them to make the test simpler.

> When I've made tests like this in the past I've usually included the C source as a comment at the top to make it easier to regenerate if needed.

I used to do that for some tests too, especially the ones that involve control flow (e.g. comments in https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/WebAssembly/exception.ll). For this code, I removed unnecessary parts from the generated code so it wouldn't be exactly the same, but I can come up with C code more or less matches the structure.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145626/new/

https://reviews.llvm.org/D145626



More information about the llvm-commits mailing list