flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Examples and Tutorials > Issues compiling long mode example ?

Author
Thread Post new topic Reply to topic
a427



Joined: 16 Oct 2015
Posts: 3
Issues compiling long mode example ?
Hello, I tried to compile the "long mode" (aka : 64 bit) example, with the linux version
of fasm 1.71.39, and I seem to get an incorrect result.

the last opcodes generated in the output file are :
$ ndisasm -b 64 simple |tail
<snip>
000000C4 48B84C204F204E20 mov rax,0x2047204e204f204c
-4720
000000CE 4889052B690B00 mov [rel 0xb6a00],rax
000000D5 EBED jmp short 0xc4

=> the "mov [rel 0xb6a00],rax" seems rather incorrect, as the source line is :
mov [0B8000h],rax

So I ported the simple.asm source to NASM, and when I compile with nasm 2.11.08, I get :
$ ndisasm -b 64 simple | tail
<snip>
000000C4 48B84C204F204E20 mov rax,0x2047204e204f204c
-4720
000000CE 4889042500800B00 mov [0xb8000],rax
000000D6 EBEC jmp short 0xc4

where here, the compile instruction "mov [0xb8000],rax" seems correct.

Do you know what could happen here ?

Thanks,
a427.
Post 16 Oct 2015, 13:56
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14505
Location: WTC Building 7
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

Post 16 Oct 2015, 14:08
View user's profile Send private message Visit poster's website Reply with quote
a427



Joined: 16 Oct 2015
Posts: 3
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 Smile
Post 16 Oct 2015, 14:15
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14505
Location: WTC Building 7

a427 wrote:
Is this some kind of optimization, that could lead to reduced code size, when referencing addresses
close to the current RIP ?

Kind of. But more useful is that it makes relocation easier.
Post 16 Oct 2015, 14:22
View user's profile Send private message Visit poster's website Reply with quote
a427



Joined: 16 Oct 2015
Posts: 3
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 Wink
Thanks again.
Post 16 Oct 2015, 14:43
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14505
Location: WTC Building 7
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.
Post 16 Oct 2015, 15:03
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867

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
Post 16 Oct 2015, 21:47
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14505
Location: WTC Building 7
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.
Post 17 Oct 2015, 03:16
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
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
Post 17 Oct 2015, 17:38
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14505
Location: WTC Building 7

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.

That is a poor example. If you can't rely on the system to execute things correctly then fix your hardware. You can't write software around that problem because the hardware might do anything.

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.

Not everyone follows your coding practices. For me, if an address is fixed in hardware I use code to access that which is also fixed, no matter where that code is positioned. Then I don't have to care about making sure the compile base and the run base are always matched.
Post 18 Oct 2015, 00:08
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
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
Post 18 Oct 2015, 13:24
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14505
Location: WTC Building 7
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.
Post 18 Oct 2015, 14:40
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 867
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
Post 18 Oct 2015, 19:22
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14505
Location: WTC Building 7
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.
Post 19 Oct 2015, 01:29
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.