[PATCH] D139097: [ARM] Add option --print-raw-value to llvm-nm to dump raw symbol values in case of ARM

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

In D139097#4068742 <https://reviews.llvm.org/D139097#4068742>, @peter.smith wrote:

> In D139097#4062420 <https://reviews.llvm.org/D139097#4062420>, @peter.smith wrote:
>
>>> @peter.smith Were you able to discuss the issue with the GNU team? Can you start a discussion on binutils at sourceware.org regarding this?
>>
>> My apologies, my day job is very busy at the moment and I've not had chance. I should be able to ask our own internal team later this week, most likely Friday.
>
> I've asked internally. I'll report back as soon as I get an answer, or next week if I don't.

I have an answer, but it is unfortunately I don't think it is going to help very much. To summarise:

- The intent of the ABI is that bit 0 of an STT_FUNC symbol is not part of the address. So printing a symbols value includes bit 0, printing a symbols address does not.
- Arm GNU tools have a "soft" preference for "higher-level, user facing" tools like objdump --syms and nm to print the address and not the value and "lower-level, developer facing" tools like readelf --symbols to print the value and not the address. You can indeed see the discrepancy arm-none-eabi-objdump --syms will force bit 0 to 0 in the output but arm-none-eabi-readelf will not. This behaviour is replicated in llvm-objdump and llvm-readelf.
- It is difficult to argue from first principles on what nm should print, GNU considers it a user-facing tool so it prints addresses.
- One shouldn't read too much into what POSIX says as it uses address and value interchangeably, essentially an assumption that the two are the same, and was likely written before Arm and Mips stashed away non address information in bit 0.
- There is no enthusiasm for changing the GNU behaviour.

So I think this still leaves us with the choice of whether llvm-nm should differ from arm-none-eabi-nm. I personally would err on the side of caution and consistency between GNU and LLVM and keep the default behaviour the same. However I don't think it will make a huge difference.


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

https://reviews.llvm.org/D139097