1/1 
|
Assembly of symbols
by firefalcon on Aug 11, 2011 |
firefalcon
Posts: 99 Joined: Jan 10, 2011 Last seen: Mar 26, 2024 |
||
|
I am wondering what the correct assembler output for this line is:
l.ori r3, r0, _some_symbol gcc returns: l.ori r0, r0, offset_of_symbol_address Note that when I replace the instruction with: l.ori r3, r0, lo(_some_symbol) I get the expected output. In the first case, it looks like the large address value is overwriting the operands. Also, should the symbol's absolute address be used as the value of the symbol here as opposed to using the relative (offset) address? |
|||
|
RE: Assembly of symbols
by jeremybennett on Aug 12, 2011 |
jeremybennett
Posts: 815 Joined: May 29, 2008 Last seen: Jun 13, 2019 |
||
|
I am wondering what the correct assembler output for this line is: l.ori r3, r0, _some_symbol gcc returns: l.ori r0, r0, offset_of_symbol_address Hi firefalcon, I don't understand your question. The first line you quote is an assembler line, not a C source line - how is gcc generating anything from it? Note that when I replace the instruction with: l.ori r3, r0, lo(_some_symbol) I get the expected output. In the first case, it looks like the large address value is overwriting the operands. Also, should the symbol's absolute address be used as the value of the symbol here as opposed to using the relative (offset) address? I think you are asking about relocation information? For relocation the assembler needs to know if a symbol is actually the upper 16 bits of an address that is being loaded. "lo" and "hi" help it determine this. I'd have to look into the details of the assembler to see exactly what it does. Is this helpful? Jeremy
-- |
|||
|
RE: Assembly of symbols
by firefalcon on Aug 12, 2011 |
firefalcon
Posts: 99 Joined: Jan 10, 2011 Last seen: Mar 26, 2024 |
||
|
I am wondering what the correct assembler output for this line is: l.ori r3, r0, _some_symbol gcc returns: l.ori r0, r0, offset_of_symbol_address Hi firefalcon, I don't understand your question. The first line you quote is an assembler line, not a C source line - how is gcc generating anything from it? I use gcc instead of as, because I need to use the preprocessor. The same holds if I just use as. Note that when I replace the instruction with: l.ori r3, r0, lo(_some_symbol) I get the expected output. In the first case, it looks like the large address value is overwriting the operands. Also, should the symbol's absolute address be used as the value of the symbol here as opposed to using the relative (offset) address? I think you are asking about relocation information? For relocation the assembler needs to know if a symbol is actually the upper 16 bits of an address that is being loaded. "lo" and "hi" help it determine this. I'd have to look into the details of the assembler to see exactly what it does. Is this helpful? Jeremy
-- I know what is happening, the 32-bit immediate is overwriting all fields of the instruction, besides the opcode, because the instruction expects a 16-bit immediate. If the symbol is an address before the instruction references it, the registers used in the instruction become r31 (0x1f). What I don't know is that if this is a feature or a bug that I should report. I personally think it is a bug. I think if you use an immediate value that is too large for the number of bits allocated in the instruction word, the immediate value should be truncated to fit. P.S. - The instruction: l.ori r3, r0, 0x12345678 gives an error, so I guess the problem is in ld |
|||
|
RE: Assembly of symbols
by firefalcon on Aug 12, 2011 |
firefalcon
Posts: 99 Joined: Jan 10, 2011 Last seen: Mar 26, 2024 |
||
|
So, even more oddness. When I assemble the instruction: l.ori r3, r0, 0x1234567, I do NOT get an error and the assembled instruction is l.ori r3, r0, 0x4567. When I assemble: l.ori r3, r0, 0x8765432, I get an error again, but not when the immediate is 0x876543. I am guessing there is a built-in limit on the value of the immediate that is causing these errors in as.
|
|||
|
RE: Assembly of symbols
by jeremybennett on Aug 12, 2011 |
jeremybennett
Posts: 815 Joined: May 29, 2008 Last seen: Jun 13, 2019 |
||
|
I know what is happening, the 32-bit immediate is overwriting all fields of the instruction, besides the opcode, because the instruction expects a 16-bit immediate. If the symbol is an address before the instruction references it, the registers used in the instruction become r31 (0x1f). What I don't know is that if this is a feature or a bug that I should report. I personally think it is a bug. I think if you use an immediate value that is too large for the number of bits allocated in the instruction word, the immediate value should be truncated to fit.
P.S. - The instruction: l.ori r3, r0, 0x12345678 gives an error, so I guess the problem is in ld Hi firefalcon, Looks like a bug - please report it. Thanks, Jeremy |
|||
|
RE: Assembly of symbols
by firefalcon on Aug 12, 2011 |
firefalcon
Posts: 99 Joined: Jan 10, 2011 Last seen: Mar 26, 2024 |
||
|
I have found that as will report and error on an immediate value >= 0x04000000.
|
|||
1/1