Index
> Tutorials and Examples > Issues compiling long mode example ? |
| Author |
|
|
revolution 16 Oct 2015, 14:08
RIP relative addressing.
The first code is using RIP as the base and adds "0xb6a00" to get the final address of "0xB8000". So nothing wrong here. This is normal. If you really need the absolute address of 0xB8000 in your code then use the dword or qword override: Code: mov [dword 0xb8000],rax |
|||
16 Oct 2015, 14:08 |
|
|
a427 16 Oct 2015, 14:15
Ah, ok I get it.
Thanks for the explanation. Is this some kind of optimization, that could lead to reduced code size, when referencing addresses close to the current RIP ? (well in this case, it adds one byte, but we can't say it's "real life" code  |
|||
|
16 Oct 2015, 14:15 |
|
|
revolution 16 Oct 2015, 14:22
a427 wrote: Is this some kind of optimization, that could lead to reduced code size, when referencing addresses |
|||
|
16 Oct 2015, 14:22 |
|
|
a427 16 Oct 2015, 14:43
Of course, like PIE or PIC..
Well, in this case (long mode) we do NOT want it, because if we relocate the code, then the target address will be wrong, as it is not RIP-related (b8000h is absolute screen address 
Thanks again. |
|||
|
16 Oct 2015, 14:43 |
|
|
revolution 16 Oct 2015, 15:03
In the case where the hardware address is fixed then of course using RIP relative addressing is wrong. But you need to tell the assembler that by using the override. In fasm RIP relative is the default when no register is specified.
|
|||
|
16 Oct 2015, 15:03 |
|
|
l_inc 16 Oct 2015, 21:47
revolution wrote: In the case where the hardware address is fixed then of course using RIP relative addressing is wrong. It's not wrong and is even better as long as the code is not meant to be position independent (why should it be?), in which case instruction size becomes the only criterion. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
16 Oct 2015, 21:47 |
|
|
revolution 17 Oct 2015, 03:16
I guess I just don't like the idea of fixed addresses being referenced as an offset to something else. I think the advantage of being able to move the code around can be useful in many cases. And it can be easy to forget when one comes back to the code after one year and adds something that moves it somewhere else and it all explodes in your face.
|
|||
|
17 Oct 2015, 03:16 |
|
|
l_inc 17 Oct 2015, 17:38
revolution
Quote: And it can be easy to forget when one comes back to the code after one year and adds something that moves it somewhere else and it all explodes in your face. This way of thinking is quite similar to biased thinking in a situation when you need to write highly reliable code for an environment with very limited debugging capabilities, in which case you may start thinking you need to put multiple jumps to the same label in succession just in case the first one fails to redirect the control flow. Thing is there's tons of code that is not meant to be position independent. And it works. If you mean to load the code somewhere else, then you change it's expected base. PIC is not written just in case. It's written when you know for sure the base is unknown. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
17 Oct 2015, 17:38 |
|
|
revolution 18 Oct 2015, 00:08
l_inc wrote: This way of thinking is quite similar to biased thinking in a situation when you need to write highly reliable code for an environment with very limited debugging capabilities, in which case you may start thinking you need to put multiple jumps to the same label in succession just in case the first one fails to redirect the control flow. l_inc wrote: Thing is there's tons of code that is not meant to be position independent. And it works. If you mean to load the code somewhere else, then you change it's expected base. PIC is not written just in case. It's written when you know for sure the base is unknown. |
|||
|
18 Oct 2015, 00:08 |
|
|
l_inc 18 Oct 2015, 13:24
revolution
Quote: You can't write software around that problem because the hardware might do anything. That's exactly my point, so I assume the example was good enough. Though it relates not only to hardware but to the code environment in general. A predefined code base is a part of the environment specification by default generally assumed to be provided. Quote: Not everyone follows your coding practices It's not just my coding practice. It's a general assumption. That's why I mentioned those tons of code that follow it. Quote: Then I don't have to care about making sure the compile base and the run base are always matched. This is what's actually wrong. Just sticking to addresses fixed by hardware gives you a fake impression of code base independence (even though it's never gonna have an undefined base), but in fact does not automatically make the code base independent, because you get screwed up as soon as you do push callback_address or mov reg64,global_var_address. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
18 Oct 2015, 13:24 |
|
|
revolution 18 Oct 2015, 14:40
I take great care over all of my global variables. In fact it is a company mandated rule here about justifying all uses of global variables. And we very commonly use relocatable code so this is not unfamiliar territory.
Anyhow, fixed hardware address make other things besides relocation easier. For another example, disassembly for verification makes it clearer about what is going to happen. Rather than having to make implicit assumptions about the run base and add that in manually. |
|||
|
18 Oct 2015, 14:40 |
|
|
l_inc 18 Oct 2015, 19:22
revolution
Quote: I take great care over all of my global variables. In fact it is a company mandated rule here about justifying all uses of global variables. My objection was not related to your code. It was related to you calling wrong something what is actually better for most common situations. Quote: Anyhow, fixed hardware address make other things besides relocation easier. For another example, disassembly for verification makes it clearer about what is going to happen. I honestly do not understand what those things are. In the vast majority of cases of disassembly the compilation base is absolutely necessary for correct disassembly. Very often it's implicitly derived by the disassembler from the fields of the corresponding file format, so no manual specification needs to be done. But even if your code is a pure binary, then you do not make an assumption, but rather explicitly specify it as something you know exactly among other disassembler settings. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
18 Oct 2015, 19:22 |
|
|
revolution 19 Oct 2015, 01:29
Unfortunately not all of our customers are so adept with disassembler settings. They love to disassemble code, because that is there mandate, but they hate to actually read things like the source code or documentation. And all the code is binary format, so no format headers or other such niceties exist.
|
|||
|
19 Oct 2015, 01:29 |
|
< Last Thread | Next Thread > |
Forum Rules:
|