OSDev.org

djgpp is not sopporting -pie or position independent code.
is there any way to make it support.

DJGPP == DOS compiler suite.

I'm going to out on a limb and say that DOS does not support position independent code or executables.

Probably not. Compile a cross compiler. See the wiki for instructions.

Is DJGPP a version of GCC? If not, you'll need to get one before you can make your cross compiler.

DJGPP is GCC for DOS.

But really, you do not want to make a cross-compiler using DJGPP. You'd end up coming across about each and every bad aspect of DOS you can imagine. And besides, DJGPP itself is dated and slightly buggy.

So I repeat:
You do not want to use DJGPP </jedi mind trick>

Combuster wrote:So I repeat:
You do not want to use DJGPP </jedi mind trick>

I do.</Jabba the Hutt>

Brynet-Inc wrote:I'm going to out on a limb and say that DOS does not support position independent code or executables.

Well, COM-files were entirely position independent, as everything resided within a single segment. EXE-files, being multi-segmented, needed fixing at load time, but the file format itself could be called position independent. So unless that's not what you meant, I have to disagree.


JAL

berkus wrote:Addresses within a segment are always 0-based. How is that position independent?

How is using CS/DS instead of EBX less position independent than 32-bits PIC?

Indeed. Segmentation can be considered position independence, albeit with a 16 byte granularity in real mode. Additionally, using segment registers saves a general purpose register of which the x86 doesn't have that many. No global offset table needed either.

So? DOS apps toss segment registers around all the time - it may be old but it's not stupid enough to limit itself to 64K code/data.

Better argument please.

Some alien bastard broke the tree limb I was standing on, but anyway, it seems DJGPP generates executables that don't run natively on DOS but using a 32-bit DOS extender, which itself may not have a realization of PIC/PIE and hence is a compiler feature NOP.

None of this is overly interesting anyway, it's all about some new user (..who's probably gone) and their attempt to wrangle a DOS compiler for OSDev.

berkus wrote:Because you need different values of CS/DS when addressing this code/data, meaning you cannot simply mix several code modules without changing CS/DS whilst calling them.

This is exactly what makes an offset table unnecessary.

Segmentation means position indepedent. All my device-drivers are position independent, and also require no relocations. This is because the linker takes the code and data selector as an input, replacing all references to code and data segments with one of these selectors. This means a device-driver can be loaded at any linear address. And segments can be 16-bit or 32-bit, so there is no size limits to this concept either.

berkus wrote:Because you need different values of CS/DS when addressing this code/data, meaning you cannot simply mix several code modules without changing CS/DS whilst calling them.

There is no need to have many different code modules in the same device in a segmented OS. It is when one device calls another that far pointers are needed, otherwise a near model works perfectly well. Just forget about the useless far memory models of old DOS. This was invented because of 16-bit limitations in DOS (and the 286), and should not be used in a segmented OS that can define segments as 32-bit if needed.