MIPS64: relocation issue

Describe the bug MIPS64 relocation handler discards the old symbol value resulting in symbols having the EA as their value. This binary is built to load at 0x0, so basically all of my .rel.dyn relocations are NULL pointers.

For example readelf shows:

000000667788  000000001203 R_MIPS_REL32     
                    Type2: R_MIPS_64        
                    Type3: R_MIPS_NONE   

with file data of: 000000667788: 00 00 00 00 XX YY ZZ WW and ghidra loads: 000000667788: 00 00 00 00 00 00 00 00

R_MIPS_REL32 handling has saveValue true and symbolIndex 0x0, resulting in symbolValue 0x0 Fall through in R_MIPS_32 extractAddend() false

R_MIPS_64 handling has saveValue false, addend 0x0, and symbolValue 0x0 resulting in overwriting the previous value with 0x0

Environment (please complete the following information):

• OS: 20.04
• Java Version: 17.0.4
• Ghidra Version: 10.2-DEV b88cf85d5cef4e766e6093223b6320ee5ae7a113
• Ghidra Origin: eclipse

[ghidra1]

I believe the intent of this relocation for symbolIndex==0 is:

R_MIPS_REL32
   value = imageBaseAdjustment + addend
   ***Assuming this is a REL type relocation, value should equal the original 
       bytes (32-bits) from the relocation address
   This value should be saved for use below
R_MIPS_64
   addend = value from above
   newValue = 0 + addend
   store value as 64-bit long

***Could the issue be caused by the R_MIPS_REL32 using the upper 32-bits instead of the lower 32-bits of the affected 64-bit location? It is using a 32-bit oldValue read from the relocation address. Since this code is shared for both 32-bit and 64-bit MIPS that oldValue read may be flawed for 64-bit MIPS and should have been a 64-bit read.

[ryanmkurtz]

Closed by 8c1fd57b72c84d99e8dca998ff0d1c22161bc4c4