Meaning of ELF64_R_SYM(rela->r_info)

[Fangrui Song]

On 2021-04-22, Peng Yu via Binutils wrote:
>>> Why "call" is used here? Isn't it better to use "call" in both the
>>> assembly code and the objdump output to make the result consistent?
>>
>> The compiler has generated a "call" instruction, but the assembler has
>> chosen to replace it with "callq", resulting in smaller/faster code.
>
>That is something that I am confused for a long time. Where is callq
>officially defined? I only see "call" on 3-138 Vol. 2A of the intel
>manual.
>
>https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html

I think bwlq suffixes are from AT&T assembly syntax.
For some instructions you cannot infer the memory operand size, e.g.

imul (%rdx)
=> Warning: no instruction mnemonic suffix given and no register operands; using default for `imul'

bwlq in this case is essential. For other cases it may be redundant.
In assembler internals, opcodes with the same mnemonic but different
operand sizes may be treated differently. The bwlq convention is useful
to make the distinction.

>> When objdump disassembles the binary file it knows nothing of the
>> original compiler output, and instead just displays the instruction that
>> is there.
>>
>> This kind of discrepancy between compiler output and actual generated
>> machine instructions is quite common, and happens for many
>> architectures, not just the x86.
>>
>>
>>> Also, this assembly code is not very human writable. For example, "s"
>>> definition is split into 5 lines. I am more familiar with nasm syntax,
>>> in which, the code can be written much short. Is the as syntax this
>>> verbose? Or it is because it is machine generated assembly code, it is
>>> OK to be verbose? What the equivalent more writable code looks like?
>>
>> The choice of how to lay out the assembler is up to the compiler.  It
>> could choose to put multiple instructions on one line, but historically
>> compilers always choose to be verbose, and only have one instruction per
>> line.
>>
>> A more compact version of the definition of s might look like this:
>>
>>    s:
>>     .globl s ; .type s, @object ; .size s, 14 ; .string "Hello World2!"
>>
>> But really, are 5 lines harder to read than 1 ?
>
>I am talking about writability which is different from readability,
>number of lines, nor the total length of code. It is about measuring
>the cost of writing/modifying the code in the typical process of
>maintaining the code.
>
>For example, the name "s" appears three times. If you want to change
>it to some other name, you will need to move the cursor and change
>three places. This is a few times more costly than the nasm way which
>I believe you just need to change one place to change a variable name.
>
>One can define a metric on how many keystrokes are needed to make the
>change in an editor (this should be editor-dependent). I think it is
>at least 2x increase in the number of keystrokes, it probably would
>increase up to 5x for vim.
>
>This wastes time when someone writes code in gas syntax.
>
>I understand gas is mainly for automatically generated code (mostly by
>gcc?). But its syntax could be defined better so that it would be more
>friendly to human writers.
>
>>> "leaq" becomes "lea" in the objdump output which is exactly the
>>> opposite of the "call" case (as "q" is added by objdump disassembly).
>>> This is again confusing. Why is so?
>>
>> This is presumably a case where the assembler decides that it is not
>> safe to use the LEAQ instruction, and so it replaces it with LEA.  (I am
>> not an x86 assembler expert, so this is guesswork on my part).
>
>I also don't find leaq on intel manual. There is only lea on Vol. 2A
>3-577 of the manual.
>
>Someone who is very familiar with the intel manual may explain this better?
>
>>> How to know when the -q version
>>> should be used when the non-q version should be used? Isn't it better
>>> to make them consistent throughout?
>>
>> Trust the assembler.  It knows that it is doing.  If it makes a change
>> to the code, there will be a good reason for it.
>
>I am not trusting the assembler. I just want to understand what is
>going on under the hood.
>
>-- 
>Regards,
>Peng