Sorry if there are other questions like this one, but I tried almost everything with no results.
I have an assembly file calling the main function of a cpp file(I'm making a kernel entry)
kerne.asm
[bits 32]
[extern _main]
jmp _main
cli
hlt
main.cpp
void a()
{
//a
}
void bc()
{
//bc
}
extern "C" int main()
{
return 0;
}
makefile
all: kes.o ke.o ke1.tmp otp.txt
kes.o : kerne.asm
nasm -f win32 -o H:\x86f\lkt\kes.o H:\x86f\lkt\kerne.asm
ke.o : main.cpp
g++ -Wall -m32 -g -std=c++14 -std=c++1y -ffreestanding -nostartfiles -c main.cpp -o ke.o
ke1.tmp : kes.o ke.o
ld -m i386pe -r -o ke1.tmp -Ttext 0x1000 kes.o ke.o
otp.txt : ke1.tmp
objdump -d ke1.tmp > otp.txt
otp.txt output
ke1.tmp: file format pe-i386
Disassembly of section .text:
00001000 <.text>:
1000: e9 00 00 00 00 jmp 1005 <.text+0x5>
1005: ee out %al,(%dx)
1006: 77 90 ja f98 <@feat.00+0xf97>
00001008 <__Z1av>:
1008: 55 push %ebp
1009: 89 e5 mov %esp,%ebp
100b: 90 nop
100c: 5d pop %ebp
100d: c3 ret
0000100e <__Z2bcv>:
100e: 55 push %ebp
100f: 89 e5 mov %esp,%ebp
1011: 90 nop
1012: 5d pop %ebp
1013: c3 ret
00001014 <_main>:
1014: 55 push %ebp
1015: 89 e5 mov %esp,%ebp
1017: 83 e4 f0 and $0xfffffff0,%esp
101a: e8 00 00 00 00 call 101f <_main+0xb>
101f: b8 00 00 00 00 mov $0x0,%eax
1024: c9 leave
1025: c3 ret
1026: 90 nop
1027: 90 nop
...
In the otp output the instruction at 1000 is the jmp _main istrunction. How you can see the address is not resolved correctly, making it point to the next instruction(1005). Where am I doing wrong?
edit:
nm kes.o
00000000 a .absolut
00000000 t .text
00000001 a @feat.00
U _main
nm ke.o
00000000 b .bss
00000000 d .data
00000000 N .debug_abbrev
00000000 N .debug_aranges
00000000 N .debug_frame
00000000 N .debug_info
00000000 N .debug_line
00000000 r .rdata$zzz
00000000 t .text
U ___main
00000000 T __Z1av
00000006 T __Z2bcv
0000000c T _main
objdump -r ke1.tmp
ke1.tmp: file format pe-i386
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000001 DISP32 _main-0x00000014
0000001b DISP32 ___main+0x00001000
RELOCATION RECORDS FOR [.debug_aranges]:
OFFSET TYPE VALUE
00000006 secrel32 .debug_info
00000010 dir32 .text-0x00001008
RELOCATION RECORDS FOR [.debug_info]:
OFFSET TYPE VALUE
00000006 secrel32 .debug_abbrev
00000088 dir32 .text-0x00001008
00000090 secrel32 .debug_line
000000a1 dir32 .text-0x00001008
000000c0 dir32 .text-0x00001008
000000d6 dir32 .text-0x00001008
RELOCATION RECORDS FOR [.debug_line]:
OFFSET TYPE VALUE
0000003a dir32 .text-0x00001008
RELOCATION RECORDS FOR [.debug_frame]:
OFFSET TYPE VALUE
00000018 secrel32 .debug_frame
0000001c dir32 .text-0x00001008
00000038 secrel32 .debug_frame
0000003c dir32 .text-0x00001008
00000058 secrel32 .debug_frame
0000005c dir32 .text-0x00001008
The reason is that with the -r
option, ld
produces an object file, not an executable. In the object file, many addresses are unset because they are to be set later by final linking (without -r
) using data from the relocation table.
@DavidWohlferd @fuz @numzero yep, the problem was the -r flag in ld. Now all the addresses are resolved correctly. Thanks to all for the help!
User contributions licensed under CC BY-SA 3.0