flat assembler
Message board for the users of flat assembler.

Index > DOS > MS COFF 16bit code, no jmp possible

Author
Thread Post new topic Reply to topic
mysli



Joined: 18 Aug 2006
Posts: 7
mysli
Hi all,

I wanted to create a MS COFF obj-File containing 16 bit code, so far so good.
Unfortunately any JMP to a label, like:

use16
...
foo: mov eax,0
...
jmp foo

gives me a failure "illegal use of symbol". If I compile the same code with use32 everything works just fine. But I need 16bit code, since it's suposed
to run under DOS. Currently I compile the same code with another assembler and code the JMP with the according hex values, but this is no fun.

So how to overcome this problem, what's the matter with MS COFF and 16bit code?

Thanks in advance,
MYSLI
Post 18 Aug 2006, 19:23
View user's profile Send private message Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
Code:
mov eax, *    
is the prob under use16 Wink
Post 18 Aug 2006, 19:46
View user's profile Send private message MSN Messenger Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7783
Location: Kraków, Poland
Tomasz Grysztar
COFF is a 32-bit format, it doesn't have 16-bit relocations.
Post 18 Aug 2006, 20:00
View user's profile Send private message Visit poster's website Reply with quote
mysli



Joined: 18 Aug 2006
Posts: 7
mysli
what do you mean by

mov eax, * ??

Actually mov eax,0 was just an example, no matter where I point the jmp to,
I always get this "illegal use of symbol", btw loop doesn't work either.

So to me it appears FASM has under this conditions (MS COFF + use16) some problems evaluating jump (loop => nothing else as jmp) locations.

MYSLI
Post 18 Aug 2006, 20:03
View user's profile Send private message Reply with quote
mysli



Joined: 18 Aug 2006
Posts: 7
mysli
Ok, COFF handles only 32bit relocations, so there is no way to overcome this problem, I must continue to code my jumps with "db 0EAh, ..." ?
Post 18 Aug 2006, 20:08
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7783
Location: Kraków, Poland
Tomasz Grysztar
In fact I would consider COFF not applicable at all for such purposes.
Post 18 Aug 2006, 20:14
View user's profile Send private message Visit poster's website Reply with quote
mysli



Joined: 18 Aug 2006
Posts: 7
mysli
The thing is, I wrote a linker which links MS COFFs, the reason is I use VC++ to write 32bit code which can be executed in protected mode, since I don't want to run this code under Windows, I needed a small loader running under DOS which brings me into protected mode and calls the 32bit code generated by VC++. I was pretty happy to find out that fasm is able to generate a MS COFF file, so my linker was right away able to interpret this file and makes an executable out of all my OBJs running under DOS. I managed this only with this few hickups I described above. Yes, you may be right, MS COFF for my loader might not be the right format, but it was pretty obvious for my needs. I think I will just live with my workarounds, anyway the loader will not be modified that often.
Post 18 Aug 2006, 21:21
View user's profile Send private message Reply with quote
okasvi



Joined: 18 Aug 2005
Posts: 382
Location: Finland
okasvi
mysli wrote:
The thing is, I wrote a linker which links MS COFFs, the reason is I use VC++ to write 32bit code which can be executed in protected mode, since I don't want to run this code under Windows, I needed a small loader running under DOS which brings me into protected mode and calls the 32bit code generated by VC++. I was pretty happy to find out that fasm is able to generate a MS COFF file, so my linker was right away able to interpret this file and makes an executable out of all my OBJs running under DOS. I managed this only with this few hickups I described above. Yes, you may be right, MS COFF for my loader might not be the right format, but it was pretty obvious for my needs. I think I will just live with my workarounds, anyway the loader will not be modified that often.


you could always make macro for jmp under use16

_________________
When We Ride On Our Enemies
support reverse smileys |:
Post 18 Aug 2006, 22:37
View user's profile Send private message MSN Messenger Reply with quote
mysli



Joined: 18 Aug 2006
Posts: 7
mysli
That's what I finally did.

BTW, it's not a problem of 32bit relocations, I would say it's a general issue with the assembler. The jumps I'm talking about are all IP relative, there are no absolute addresses which would be relocated by any linker.

What I now did is:

foo: any code
....
db 0E9h ;IP relative JMP -> same as jmp foo
db foo - $

So there is no need of any relocation since the assembler calculates the IP relative distance to the destination address. This is the same for any conditional jump, they don't work either, although to me there is not really a reason imaginable why not the assembler calculates this relative jumps. Tomasz?

Regards,
Mysli
Post 20 Aug 2006, 11:27
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7783
Location: Kraków, Poland
Tomasz Grysztar
If you do "jmp dword foo" (even "jmp short dword foo") it's going to work correctly. However with "use16" the jumps are "word" ones by default, and those jumps modify IP only (clearing the high 16 bits of EIP). Since the "foo" is a 32-bit relocatable value that in most cases will probably not fit in 16 bits, such instruction cannot be ensured to work properly and thus assembler gives you "invalid use of symbol" error.
Post 20 Aug 2006, 12:14
View user's profile Send private message Visit poster's website Reply with quote
mysli



Joined: 18 Aug 2006
Posts: 7
mysli
Why do you consider "foo" in my example as a relocatable value, to me it just represents a value of the IP. A relocatable value to me is a variable where I don't know its address during design of the code, and which depents on the absolute location in memory during execution, but I think this is not the case for the label "foo", its address is independent of the absolute location in memory and therefore no relocation is needed. "foo" will also not show up in the relocation table of the COFF later on.

How do you do this for "binaries", how are jumps evaluated there?

Would there be the chance to force the assembler to take only 16bit of the
EIP into account, i.e.

jmp word foo

or

jc word foo

or what ever. Then it would be up to the programmer to use the right wording to generate the right code.

One more question, in general does the "use16" directive also effect the default width of the (E)IP or just the usage of the prefixes 66h/67h?

Regards,
Mysli
Post 21 Aug 2006, 11:05
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7783
Location: Kraków, Poland
Tomasz Grysztar
mysli wrote:
Why do you consider "foo" in my example as a relocatable value, to me it just represents a value of the IP. A relocatable value to me is a variable where I don't know its address during design of the code, and which depents on the absolute location in memory during execution, but I think this is not the case for the label "foo", its address is independent of the absolute location in memory and therefore no relocation is needed. "foo" will also not show up in the relocation table of the COFF later on.

All the data and code in the linkable objects is relocatable and thus all the labels are relocatable. After linking the "foo" may happen to be 1200h, but it may happen to be 7000000h also.

mysli wrote:
How do you do this for "binaries", how are jumps evaluated there?

Since those formats (and also ELF executables, PE without fixups or MZ) are not linkable and thus use absolute ('known') addresses, which then are nothing but ordinary numbers, you can use them in any way as you would use any given number. Thus even the things like:
Code:
jmp (foo*foo)/bar    

are possible with absolute labels (if only you'd find some use for it).

mysli wrote:
Would there be the chance to force the assembler to take only 16bit of the
EIP into account, i.e.

jmp word foo

As I said, the COFF format doesn't have 16-bit relocations - which is exactly what is needed to force the LINKER to make it work.
The OMF objects would work for it but fasm doesn't support that format.

mysli wrote:
One more question, in general does the "use16" directive also effect the default width of the (E)IP or just the usage of the prefixes 66h/67h?

There is no such thing as "default width of the (E)IP" in fasm. The addresses are actually 64-bit internally, but as long as the label fits in 32 bits, the "jmp dword" to that label can be generated, etc. With the relocatable formats there is the default size (usually 32 bits) for the address value that can be relocated and thus addresses are assumed to fit in those boundaries (unless the offset value is already larger than 32 bits) and it's linker's job to ensure that after relocating the values are still in correct range.
Post 21 Aug 2006, 11:16
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


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.