rv64: bug in encoding of bge?

[Jim Wilson]

On 1/10/19 12:09 AM, Paulo Matos wrote:
> 
> 
> On 10/01/2019 08:02, Paulo Matos wrote:
>> Of course, I was totally confused because the dump shows
>>   bge     a2,a1,0
>> and my eyes were glossing over the <foo> at the end of each line.
>> Therefore I expected that all instructions should be looping to themselves.
>>
>> But the original code has them all looping back to foo.
>>
>> Got it, thanks.
> 
> In order to confirm my suspicion, the bge (and other branches) take an
> address as the third argument, the assemble then subtracts the PC from
> it and puts the result into the offset field of the instruction. Is this
> correct?

That is basically correct.  There are a number of complications.  Can 
the address be computed at assembly time?  Can the address change at 
link time (via relaxation)?  If there is a reloc, it is in place or not? 
  If we have an in place reloc, then an assembler computed value is 
stored in the instruction which is used at link time when the reloc is 
resolved.  If we don't have an in place reloc, then no value is stored 
in the instruction and the instruction field is just overwritten at link 
time when the reloc is resolved.  If you want simpler instructions to 
look at, do a link, and avoid looking at unlinked object files.  If you 
do look at object files, then it is a good idea to get in the habit of 
using "objdump -dr" so you can see the relocs, as Florian mentioned. 
The code will make more sense if you can see the relocs.

Jim