Can't link c++ function in assembly

Question

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

It's not just the jump, all the addresses are 0. Possibly the result of linking with `-r`? If everything is relocatable, that means a dump of the static image can't show the correct addresses for labels, until they get resolved at load/run time. What do you see if you load this into the debugger? — David Wohlferd, Apr 19 '20 at 04:39
Please add the output of `nm ke.o` and `nm kes.o`. I'd like to confirm that the name mangling is done correctly on both ends. `objdump -r ke1.tmp` might help as well. — fuz, Apr 19 '20 at 10:03
@frgr You can see the relocation to be patched in at address `00000001` in the `.text` section for `_main`. This is indeed a consequence of the `-r` option to `ld`. Why have you added it? — fuz, Apr 19 '20 at 12:38

score 1 · Accepted Answer · answered Apr 19 '20 at 16:02

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 Apr 19 '20 at 16:02

numzero

2,009
6
6

score 0 · Answer 2 · answered Apr 20 '20 at 15:19

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 Apr 20 '20 at 15:19

frgr

43
3

Can't link c++ function in assembly

2 Answers2