[PATCH] D73542: [LLD][ELF][ARM] Do not substitute BL/BLX for non STT_FUNC symbols.

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Feb 8 01:00:03 PST 2020


psmith added a comment.

Thanks for checking out the problem. I agree that this is a change in behaviour that isn't obvious to new authors of Arm assembler, and we have enough of a legacy of binaries that other people may be affected.

I think an assembler warning would probably not be as helpful as a linker one as the assembler can only catch the problem when there is a definition and a reference in the same .s file. For example:

  .text
  .global foo
  
  bl foo

foo has type STT_NOTYPE (it's just a reference), what is important is that the definition of foo has type STT_FUNC, which may not have any references to it at all in the same file.

The linker knows the merged symbol type and can give a better warning. There are a couple of ways that I think we could do it:

- Give a warning when LLD will change its behaviour from the previous version, and a hint on how to fix it, I think that this is only possible when there is a thumb BL to a STT_NOTYPE symbol, as STT_NOTYPE symbols that are labels have the bottom bit clear and look to LLD like ARM.
- A more expensive check that uses the mapping symbols ($t, $a and $d) these symbols denote the Thumb, Arm and Literal data ranges, if we get a STT_NOTYPE symbol we can lookup the closest previous mapping symbol, we can either autocorrect the STT_NOTYPE feature or give a warning if they disagree. This does require a scan through the objects symbol table, but it given that we don't expect this to happen often then it would be worth it as part of an exceptional case.

I'm happy to work on either, although I think starting with the smallest change would be a good way to start.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73542





More information about the llvm-commits mailing list