Way to combine 16 and 32 bit code in object file

Index > OS Construction > Way to combine 16 and 32 bit code in object file

Author

Thread

Night Rider

Joined: 28 Jul 2005
Posts: 72

Night Rider 02 Mar 2019, 20:20

Hi, All!

Let's say I have something like

Code:

use16
...
DW label1
...
some 16 bit code
...

use32

label1:
32 bit code here

I would need to truncate the 32 bit pointer and use lowest part in the first, 16 bit section of code.
Now, I need to have PECOFF/ELF object file format with custom linking and custom further processing.

Is it possible to combine 16/32 bit code in such a manner for standard object files? Or what would be the best way to do it? Create 2 separate files, one is with 16 bit code, second with 32 bit and make some custom linking?
What are my options? Probably having several sections or something like that?

Thanks in advance.

_________________
My best regards

02 Mar 2019, 20:20

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20461
Location: In your JS exploiting you and your system

revolution 02 Mar 2019, 20:26

For which OS?

With fasm you can combine code with different bitness in any object format, but you need to find a way to switch the OS to a mode for running the code.

In windows you can change the CS value to get 16-bit execution (it is undocumented though). In Linux there is no support for 16-bit AFAICT.

02 Mar 2019, 20:26

Night Rider

Joined: 28 Jul 2005
Posts: 72

Night Rider 02 Mar 2019, 20:31

revolution wrote:

For which OS?

With fasm you can combine code with different bitness in any object format, but you need to find a way to switch the OS to a mode for running the code.

In general for raw hardware.
(Redesigning my old hobby os. Previously I used raw binary output - no problem with mixing code whatsoever. Now I'm going to compile it as object files to include code from other languages, hence I need to output an object file that would be later linked with other object files and then using objconv or something similar to produce raw binary again).

_________________
My best regards

02 Mar 2019, 20:31

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20461
Location: In your JS exploiting you and your system

revolution 02 Mar 2019, 20:41

I moved this to OS Construction.

There is no standard on PE or ELF that defines mixing bitness. So you need to create your own.

You can make it as simple as simply defining a new section/segment for each bitness and then keep track of that within your code.

Or you could define it as each file uses a single bitness and load them separately at startup.

02 Mar 2019, 20:41

Night Rider

Joined: 28 Jul 2005
Posts: 72

Night Rider 02 Mar 2019, 20:55

revolution wrote:

I moved this to OS Construction.
You can make it as simple as simply defining a new section/segment for each bitness and then keep track of that within your code.

OK, so still I can have different sections for 16 and 32 bit in one file? But will I be able to reference point in 32 bit section from 16 bit one?

_________________
My best regards

02 Mar 2019, 20:55

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20461
Location: In your JS exploiting you and your system

revolution 02 Mar 2019, 21:00

You will need some sort of call gate to switch execution modes. That part will be OS dependant.

For data accesses you can just access them normally in either mode.

You can setup your segment registers for each mode to overlap each other if that makes sense in your code. Or you can separate them entirely. For example you could put all your 16-bit code at <1MB and all the 32-bit code at >=1MB. It just depends upon your requirements for the OS and tasks it is performing.

02 Mar 2019, 21:00

Night Rider

Joined: 28 Jul 2005
Posts: 72

Night Rider 02 Mar 2019, 22:15

revolution wrote:

You will need some sort of call gate to switch execution modes. That part will be OS dependant.

For data accesses you can just access them normally in either mode.

You can setup your segment registers for each mode to overlap each other if that makes sense in your code. Or you can separate them entirely. For example you could put all your 16-bit code at <1MB and all the 32-bit code at >=1MB. It just depends upon your requirements for the OS and tasks it is performing.

This is absolutely unrelated and redundant. I am aware about CPU modes and memory models (after all, I have working hobby OS); my question is entirely about object file format and output of FASM.

Probably it needs some rephrasing. I mean - you can set two sections in the one and same object file, whereas one section is 16 bit, another is 32 bit? And I should be able to reference (I mean in assembly) one section from another? But mapping of sections in memory can be different :-/ Will then cross-section references be resolved by linker, if sections are of different "bitness"?

Seems I need to RTFM more regarding object file format.

_________________
My best regards

02 Mar 2019, 22:15

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20461
Location: In your JS exploiting you and your system

revolution 02 Mar 2019, 23:08

Well sorry, I don't know what you have done, I was just trying to cover the bases here.

The thing to realise is that there is no object file format that defines anything to do with mixing bitness. Like I mentioned you will have to create your own.

Fasm can assemble code in any way you want, but the output format will have to be your design. You can enclose your code in ELF or PE if you wish to, but the format itself doesn't support any notion of defining different parts as having different bitness. That will be entirely on your decision as to how to mark each section for its associated bitness.

02 Mar 2019, 23:08

alexfru

Joined: 23 Mar 2014
Posts: 80

alexfru 03 Mar 2019, 09:18

I think the simplest is to build the full 32-bit (or 16-bit) part and include it as a binary blob in the other, 16-bit (or 32-bit) part. Or simply concatenate the two parts. There isn't much connection between the two parts anyway (or you can minimize those).

03 Mar 2019, 09:18

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 03 Mar 2019, 10:44

I recall that OMF format should be able to contain both 16-bit and 32-bit code segments. Unfortunately I never attempted to make OMF support for fasm, though I still consider it one of the things I may make with fasmg in future.

03 Mar 2019, 10:44

Night Rider

Joined: 28 Jul 2005
Posts: 72

Night Rider 03 Mar 2019, 16:12

alexfru wrote:

I think the simplest is to build the full 32-bit (or 16-bit) part and include it as a binary blob in the other, 16-bit (or 32-bit) part. Or simply concatenate the two parts. There isn't much connection between the two parts anyway (or you can minimize those).

I came to the same conclusion. Seems I need to concat two different parts.

One problem I have is that I'm referencing 32 bit part from the 16 bit world. Like some of GDT/IDT entries stored in the 16 bit part have some references to 32 bit code and so on Confused

_________________
My best regards

03 Mar 2019, 16:12

Night Rider

Joined: 28 Jul 2005
Posts: 72

Night Rider 03 Mar 2019, 16:17

revolution wrote:

but the format itself doesn't support any notion of defining different parts as having different bitness. That will be entirely on your decision as to how to mark each section for its associated bitness.

That's for sure. I could just switch FASM modes using use16/use32 on demand within one section.
Referencing points in the use32 part from use16 part is problematic. Say, I need offset of label in use32 portion, but in 16 bit notation (truncated).

I guess I will have to go down the way of separating two parts.

Thanks everyone!

_________________
My best regards

03 Mar 2019, 16:17

bzt

Joined: 09 Nov 2018
Posts: 79

bzt 05 Mar 2019, 00:38

Night Rider wrote:

Referencing points in the use32 part from use16 part is problematic. Say, I need offset of label in use32 portion, but in 16 bit notation (truncated).

Truncate won't work. I suggest to create a 32 bit output format, and in the 16 bit code sections you must use a translate table (or calculate the address in run time). All 32 bit labels must be translated into a 16 bit segment+offset pair to point to the same address in memory (up to limit of the 16 bit addressable address space of course).

Code:

use16
; assuming there's a 32 bit address in esi
mov eax, esi
shr ax, 4
mov ds, ax
and si, 0Fh
; now you can use ds:si

Alternatively you can set up unreal mode (which includes a special GDT), that way you can address the 32 bit parts anywhere in the 4G address space directly from a 16 bit code segment.

Cheers,
bzt

05 Mar 2019, 00:38

< 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