Can't link c++ function in assembly

4

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
c++
assembly
linker
operating-system
kernel
asked on Stack Overflow Apr 19, 2020 by frgr • edited Apr 19, 2020 by frgr

2 Answers

1

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.

answered on Stack Overflow Apr 19, 2020 by numzero
0

@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!

answered on Stack Overflow Apr 20, 2020 by frgr

User contributions licensed under CC BY-SA 3.0