Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order
shwonder(R)

Haifa, Israel,
23.01.2008, 17:10
(edited by shwonder, 23.01.2008, 18:28)
 

DJGPP + HDPMI problem: unresolved symbols (Developers)

Hi

I'm trying to compile SAMPLES\djgpp\hello.c, expecting to get stand alone executable, containing HDPMI. But I have unresolved symbols. I do the following steps:

1. gcc -c Hello.c -oHello.o
2. ld -r -x -s -T ../../lib/djgpp.ld -oHello.bin -Map hello_.map ../../lib/crt0hx.o Hello.o -lm -lc
3. ..\..\BIN\ldfix Hello.bin
4. \mingw\bin\ld -e start -o Hello.exe -Map Hello.map -pie Hello.bin
5. ..\..\BIN\pestub -q -n -w -x Hello.exe ..\..\BIN\dpmist32.bin

at step 4 I get the following errors:

Hello.bin:(.text+0x10): undefined reference to `__djgpp_ds_alias'
Hello.bin:(.text+0x2b): undefined reference to `_crt0_startup_flags'
Hello.bin:(.text+0xe2b1): undefined reference to `__djgpp_stack_top'

I found, that in original crt0.o, supplied with DJGPP, these symbols exist, but in crt0hx.o they don't. The comment in crt0hx.S says, that __djgpp_ds_alias, for example should be defined at go32\exception.S, but it isn't there.

I tried to work around the problem, by declaring the these symbols in hello.c:

---[ cut ]---
unsigned short __djgpp_ds_alias;
unsigned long __djgpp_stack_top;
int _crt0_startup_flags;
---[ cut ]---

In this case I'm able to get an executable, but when I try to run, it crashes with SIGSEGV at 004017e5.

I'm using djgpp suite ver. 2.0.4,
gcc 4.22,
g++ 4.22
Latest HXRT (2.13)

Thanks!

Japheth(R)

Homepage

Germany (South),
23.01.2008, 18:34

@ shwonder

DJGPP + HDPMI problem: unresolved symbols

> 1. gcc -c Hello.c -oHello.o
> 2. ld -r -x -s -T ../../lib/djgpp.ld -oHello.bin -Map hello_.map
> ../../lib/crt0hx.o Hello.o -lm -lc
> 3. ..\..\BIN\ldfix Hello.bin
> 4. \mingw\bin\ld -e start -o Hello.exe -Map Hello.map -pie Hello.bin
> 5. ..\..\BIN\pestub -q -n -w -x Hello.exe ..\..\BIN\dpmist32.bin
>
> at step 4 I get the following errors:

In step 4 I used a MS COFF linker. I'm pretty sure that the mingw LD can NOT be used as a replacement, but I forgot the reason why.

IIRC I used MS link from the Win2k DDK to link the sample, but I just tried the one contained in VC EE 2005, and it works as well.

The GCC version I used tells it is v4.1. Is this DPJGG v2.03 or v2.04?

---
MS-DOS forever!

shwonder(R)

Haifa, Israel,
23.01.2008, 18:49

@ Japheth

DJGPP + HDPMI problem: unresolved symbols

> > 1. gcc -c Hello.c -oHello.o
> > 2. ld -r -x -s -T ../../lib/djgpp.ld -oHello.bin -Map hello_.map
> > ../../lib/crt0hx.o Hello.o -lm -lc
> > 3. ..\..\BIN\ldfix Hello.bin
> > 4. \mingw\bin\ld -e start -o Hello.exe -Map Hello.map -pie Hello.bin
> > 5. ..\..\BIN\pestub -q -n -w -x Hello.exe ..\..\BIN\dpmist32.bin
> >
> > at step 4 I get the following errors:
>
> In step 4 I used a MS COFF linker. I'm pretty sure that the mingw LD can
> NOT be used as a replacement, but I forgot the reason why.
>
> IIRC I used MS link from the Win2k DDK to link the sample, but I just
> tried the one contained in VC EE 2005, and it works as well.
>
> The GCC version I used tells it is v4.1. Is this DPJGG v2.03 or v2.04?

Checked again with link.exe from WinDDK 2600.1106:

4. link Hello.bin /nologo /subsystem:console /entry:start /out:Hello.exe /fixed:no /map:Hello.map /FileAlign:0x200

Without work around:
Hello.bin : error LNK2001: unresolved external symbol ___djgpp_stack_top
Hello.bin : error LNK2001: unresolved external symbol ___djgpp_ds_alias
Hello.bin : error LNK2001: unresolved external symbol __crt0_startup_flags
Hello.exe : fatal error LNK1120: 3 unresolved externals

with workaround, linked ok, but SIGSEGV at running:

E:\localSVN\trunk\OEM_TO~1\DevTools>Hello.exe
Exiting due to signal SIGSEGV
General Protection Fault at eip=02992f25
eax=00000010 ebx=fffffffc ecx=00000018 edx=00000010 esi=00000018 edi=00000008
ebp=02abffa8 esp=02abff90 program=<**UNKNOWN**>
cs: sel=01af base=00000000 limit=7ffeffff
ds: sel=01b7 base=00000000 limit=7ffeffff
es: sel=01b7 base=00000000 limit=7ffeffff
fs: sel=0000
gs: sel=01ef base=00000000 limit=0010ffff
ss: sel=01b7 base=00000000 limit=7ffeffff
App stack: [00000000..38ebc033] Exceptn stack: [0299f3a0..0299d460]

Call frame traceback EIPs:
0x02992f25

Japheth(R)

Homepage

Germany (South),
23.01.2008, 19:16

@ shwonder

DJGPP + HDPMI problem: unresolved symbols

> Without work around:
> Hello.bin : error LNK2001: unresolved external symbol ___djgpp_stack_top
> Hello.bin : error LNK2001: unresolved external symbol ___djgpp_ds_alias
> Hello.bin : error LNK2001: unresolved external symbol
> __crt0_startup_flags
> Hello.exe : fatal error LNK1120: 3 unresolved externals
>
> with workaround, linked ok, but SIGSEGV at running:

These variables aren't dummies, just defining them somewhere sounds like a not so good idea. At least 2 of them are also used by the crt0hx.s startup code.

I checked the DJGPP version I used, it was v2.03! That means, the DJGPP v2.04 prerelease is NOT supported.

---
MS-DOS forever!

shwonder(R)

Haifa, Israel,
23.01.2008, 19:21

@ Japheth

DJGPP + HDPMI problem: unresolved symbols

> > Without work around:
> > Hello.bin : error LNK2001: unresolved external symbol
> ___djgpp_stack_top
> > Hello.bin : error LNK2001: unresolved external symbol ___djgpp_ds_alias
> > Hello.bin : error LNK2001: unresolved external symbol
> > __crt0_startup_flags
> > Hello.exe : fatal error LNK1120: 3 unresolved externals
> >
> > with workaround, linked ok, but SIGSEGV at running:
>
> These variables aren't dummies, just defining them somewhere sounds like a
> not so good idea. At least 2 of them are also used by the crt0hx.s startup
> code.
>
> I checked the DJGPP version I used, it was v2.03! That means, the DJGPP
> v2.04 prerelease is NOT supported.

Yes, I see. I tried with 2.03 and it worked fine. I'll try to diff crt0.s from 2.03 & crt0.s from 2.04 and to apply the changes on crt0hx.s... What do you say, can it succeed?

DOS386(R)

24.01.2008, 01:34

@ shwonder

DJGPP trouble

> to compile SAMPLES\djgpp\hello.c, expecting to get stand alone executable

Indeed CC386 is much easier to use and debug ... OTOH MPLAYER probably would be much more difficult to port with it :crying:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth(R)

Homepage

Germany (South),
24.01.2008, 05:27

@ shwonder

DJGPP + HDPMI problem: unresolved symbols

> Yes, I see. I tried with 2.03 and it worked fine. I'll try to diff crt0.s
> from 2.03 & crt0.s from 2.04 and to apply the changes on crt0hx.s... What
> do you say, can it succeed?

What do you want to hear? Yes, it can succeed, but it is more likely to fail. I will look at it, but it may require some time. I'm busy with other things.

---
MS-DOS forever!

Japheth(R)

Homepage

Germany (South),
24.01.2008, 06:15

@ DOS386

DJGPP trouble

> Indeed CC386 is much easier to use and debug ...

Good to hear that it is easy to debug. But how? Can GRDB be used to debug it? Or do you use the LadSoft Windows IDE for debugging? :-D

---
MS-DOS forever!

DOS386(R)

19.02.2008, 02:44

@ Japheth

[de]BUGging

> Good to hear that it is easy to debug. But how? Can GRDB be used to debug it?

Less bloated, less messy, better syntax :-P

> Or do you use the LadSoft Windows IDE for debugging?

NO.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo(R)

Homepage

Usono,
19.02.2008, 03:28

@ Japheth

DJGPP trouble

> > Indeed CC386 is much easier to use and debug ...
>
> Good to hear that it is easy to debug. But how? Can GRDB be used to debug
> it? Or do you use the LadSoft Windows IDE for debugging? :-D

You can enable the built-in GRDB-ish asm-level debugger (basically the same core, I think). But I haven't tried recently.

Back to the board
Thread view  Mix view  Order
15192 Postings in 1365 Threads, 250 registered users, 12 users online (0 registered, 12 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum