Near and Far JMPs

Question

I am doing Linux assembly and I understand that is has a flat memory model. What I am confused about is NEAR and FAR JMPs.

NEAR is in the same segment while FAR is another segment. From what I understand there are no segments in linux virtual memory? Also how do we know if my program's code is laid out in multiple segments?

Solution 1

It hasn't been segments for a long time now. The correct term in protected mode x86 is selector.

Having said that, the difference between a near jump and a far one is that the former maintains the same code selector cs while the latter (usually) changes it.

In a flat memory model, the former case is almost always how it's done.

You could have an operating system where the flat memory model is served by multiple selectors but I can't see a useful use case for it, and it's not the way Linux works, at least on x86.

Solution 2

NEAR is in the same segment while FAR is another segment.

A near jump jumps to a location within the current code segment (pointed to by cs). A far jump is normally used to jump to a location within a different code segment, but it can jump to a location within the current segment as well, if the segment selector in the far address coincides with the value in cs.

From what I understand there are no segments in linux virtual memory?

I wouldn't be surprised to find Linux ports to CPUs using some kind of segmented memory. So, I'd say it depends. You're unlikely to see Linux use segments on the x86 platform, though. But again, you or someone else could make a small Linux running in real mode and using segments.

Also how do we know if my program's code is laid out in multiple segments?

You check the CPU and OS. Naturally, if you write portable C code, this should be of no concern to you.

Solution 3

From what I understand there are no segments in linux virtual memory?

It's accurate enough. There are thread-specific data with a location pointed by %fs segment base, but there is no segments suitable for far jumps.

Also how do we know if my program's code is laid out in multiple segments?

If your target platform is Linux, you already know it is not. (I would be surprised if any modern OS still uses segments in a way which makes jump far make sense).

Comments

[ST-User]

The why do we even need far jmps? when we don't change segments?

[ST-User]

Can you give me an example when i would have to change a selector for a FAR JMP? I am confused about real world usage

[ST-User]

Can you gimme a real world example of a far jmp? I am confused as to when to prefix "far" say I write a very large program in assembly.

[Alexey Frunze]

If it's a very large 16-bit program and its code does not fit into one 64KB segment, you split it into multiple segments (each smaller than 64KB) and then pass control to the routines using either a far call or a far jump. Obviously, far calls and far returns must be matching, you shouldn't use a near call and then return with a far return or vice versa.

[paxdiablo]

@ST-User: sure. Let's say you have an OS where the bottom 3G is user code and the OS allows self-modifying code. That would mean the user-code selector would allow read/write access. However, the OS services sits in the top 1G and doesn't want you messing about with it, so the selector for that would be read-only (well, execute as well). That's one possibility. But keep in mind that's a contrived example - I know of no modern OS that does this simply because they prefer to keep things simple.

[Anton Kovalenko]

On modern systems with flat memory model you don't need far jumps except in very special circumstances, like entering protected mode.

[ST-User]

But if the OS is Linux and already running in protected mode + flat memory model, then do we ever need Far JMPs?

[ST-User]

No i meant example for a moder IA-32 powered Linux OS using protected mode + flat memory model. Not the older 16bits ones.

[ST-User]

Do you mean then that in modern OSs there is no Far Jmp required at all? It only comes into picture for the older 16 bit stuff where we used the segment registers for locating segments?

[Alexey Frunze]

You can still use segments in a similar fashion in protected mode, it's just that now you'll need to have segment descriptors in the GDT (or LDT) to define segments explicitly unlike in real mode, where the only segment attribute that is variable is the segment base and it's directly computable from the selector/segment. In protected mode more uses are possible. I'm sorry, but your question is still unclear. Want to find out more about the possible options? Read the Intel CPU manual. Restating it here is impractical.

[paxdiablo]

@ST-User: yes, although it's not necessarily quite that simple (since "flat memory" has meaning at multiple levels. For a layman, you could just consider that each process gets a 4G address space (in a "keep-it-simple" OS) and only needs one code selector, one data selector and one stack selector within that 4G. In that case, no far jumps are ever required. In a much more complex situation, you may have code scattered amongst many different code regions, each with their own selector - that would need far jumps.

[ST-User]

So as a assembly language programmer how can I know that my code is spread over multiple segments? and then use far jmp?

[paxdiablo]

As an assembly language programmer, you control that. Assembly language is where you can muck about with selectors (OS permitting, of course). If you're not doing far jumps and/or setting up LDT/GDT entries,, then you're almost certainly within a single selector.

[Peter Cordes]

@ST-User: No, you don't ever need a far jmp in user-space or kernel mode on Linux. All user-space processes use the same CS segment selector (CPL=3 = ring 3 user mode), and the kernel uses a different one (CPL=0 = ring 0 kernel mode). You only switch between them via interrupts / exceptions and instructions like int, sysenter or syscall to enter kernel mode and iret to restore cs:eip or cs:rip from the kernel stack, or sysret. Unless you want to do unstable silly computer tricks like changing to 32-bit mode in a process that started as 64-bit, there's zero reason to jmp far.