OSDev.org

Posted: **Sat Aug 02, 2014 9:15 am**

I'm writing an x86_64 kernel in C++ with a g++ 4.9.1 cross-compiler (target is x86_64-elf). I've just written the crt{i,n}.o stubs and linked them into my kernel, along with the cross-compiler's crtbegin.o and crtend.o but I'm still getting relocation errors:

Code: Select all

[...]/lib/gcc/x86_64-elf/4.9.1/crtbegin.o: In function `deregister_tm_clones':
crtstuff.c:(.text+0x1): relocation truncated to fit: R_X86_64_32 against symbol `__TMC_END__' defined in .jcr section in [...]/kernel-x86_64-elf.0.1
crtstuff.c:(.text+0x21): relocation truncated to fit: R_X86_64_32 against `.tm_clone_table'
[...]/lib/gcc/x86_64-elf/4.9.1/crtbegin.o: In function `register_tm_clones':
crtstuff.c:(.text+0x41): relocation truncated to fit: R_X86_64_32 against symbol `__TMC_END__' defined in .jcr section in [...]/kernel-x86_64-elf.0.1
crtstuff.c:(.text+0x6f): relocation truncated to fit: R_X86_64_32 against `.tm_clone_table'
[...]/lib/gcc/x86_64-elf/4.9.1/crtbegin.o: In function `__do_global_dtors_aux':
crtstuff.c:(.text+0x8f): relocation truncated to fit: R_X86_64_32 against symbol `__DTOR_END__' defined in .dtors section in [...]/lib/gcc/x86_64-elf/4.9.1/crtend.o
crtstuff.c:(.text+0xe6): relocation truncated to fit: R_X86_64_32 against `.eh_frame'
[...]/lib/gcc/x86_64-elf/4.9.1/crtbegin.o: In function `frame_dummy':
crtstuff.c:(.text+0x10f): relocation truncated to fit: R_X86_64_32 against `.bss'
crtstuff.c:(.text+0x114): relocation truncated to fit: R_X86_64_32 against `.eh_frame'
crtstuff.c:(.text+0x11e): relocation truncated to fit: R_X86_64_32 against `.jcr'
[...]//lib/gcc/x86_64-elf/4.9.1/crtend.o: In function `__do_global_ctors_aux':
crtstuff.c:(.text+0x6): relocation truncated to fit: R_X86_64_32 against `.ctors'
abi/cxa_guard.o:(.debug_info+0x6): additional relocation overflows omitted from the output
'

Here are my CXFLAGS:

Code: Select all

-Wall -Wextra -pedantic -nostdlib -mno-red-zone -mno-sse -mno-sse2 -mno-sse3 -mno-3dnow -gdwarf-2 -ffreestanding -nostdlib -fno-builtin -static --no-common -mcmodel=kernel -O0

and my LDFLAGS:

Code: Select all

-nostdlib -z max-page-size=0x1000 -Tlink.ld -static

And my (admittedly really messy) linker script:

Code: Select all

ENTRY(_start32)
PHYS_ADDR = 0x0000000000100000;
VIRT_ADDR = 0xFFFFFFFF80000000;
SECTIONS
{
    /* The 32-bit bootstrap at PHYS_ADDR.
     */
    . = PHYS_ADDR;
    .boot : {
        *(.multiboot)
        __boot_start__ = .;
        *(.boot_text)
        *(.boot_rodata)
        *(.boot_data)
        . = ALIGN(4096);
        __pml4__ = .;
        . += 0x1000;
        __pdpt__ = .;
        . += 0x1000;
        __pdir__ = .;
        . += 0x2000;
        __boot_stack__ = .;
        __boot_end__  = .;
    }
    /* The 64-bit kernel at virtual address VIRT_ADDR.
     */
    . += VIRT_ADDR;
    __kernel_start__ = . - VIRT_ADDR;
    .text ALIGN(0x1000) : AT(ADDR(.text) - VIRT_ADDR)
    {
        __kernel_text__ = . - VIRT_ADDR;
        *(.init*)
        *(.gnu.linkonce.i*)
        *(.fini*)
        *(.gnu.linkonce.f*)
        *(.text)
        *(.gnu.linkonce.t*)
        __kernel_rodata__ = . - VIRT_ADDR;
        *(.rodata*)
        *(.gnu.linkonce.r*)
    }
    .data ALIGN(0x1000) : AT(ADDR(.data) - VIRT_ADDR)
    {
        __kernel_data__ = . - VIRT_ADDR;
        *(.data)
        *(.gnu.linkonce.d*)
    }
    .eh_frame ALIGN(0x1000) : AT(ADDR(.eh_frame) - VIRT_ADDR)
    {
        __kernel_eh_frame__ = . - VIRT_ADDR;
        *(.eh_frame)
        *(.gnu.linkonce.e*)
    }
    .bss ALIGN(0x1000) : AT(ADDR(.bss) - VIRT_ADDR)
    {
        __kernel_bss__ = . - VIRT_ADDR;
        *(COMMON)
        *(.bss)
        *(.gnu.linkonce.b*)
    }
    __kernel_end__ = . - VIRT_ADDR;
    /* Debugging symbols will be stripped later, so they go after __kernel_end__.
     */
    .debug : {
        *(.debug*)
        *(.dwarf*)
        *(.gnu.linkonce.d*)
    }
    /DISCARD/ : {
        *(.comment)
        *(.stab)
    }
}

These relocation errors seem to be in the cross-compilers code and not mine (I had some relocation problems but I solved them; partly by discarding stabs stuff). Does that mean I need to recompile something? I couldn't find anything on the net about these particular relocation errors, and I couldn't fix it by myself based on the errors I've had before.

Edit:

I have tried using -mcmodel=large, -fPIC (together and separately) and -m64 but I got the same errors
I've read this thread: http://forum.osdev.org/viewtopic.php?f=1&t=28066 but it wasn't solved. Right now I'm seeing whether recompiling crt* will work.

Posted: **Sat Aug 02, 2014 2:29 pm**

I don't think its possible to have crtbegin/crtend linked anywhere outside of the first 4 GiB of address space. The issue is that libgcc/crtstuff.c generates lots of code of the form mov eax, label (as imm32). The use of this form, rather than mov rax, label (as imm32), means that the label is not sign-extended to 64-bits by the CPU and so negative values cannot be used. Thus R_X86_64_32 references are used in the crtbegin/end.o files, instead of R_X86_64_32S ones, and the linker rightly complains. I'd imagine this behaviour is due to Linux running user space programs at a low address (and so this isn't an issue for them) and them not using C++ in the kernel.

All I can suggest is either linking crtbegin/end to a low address, or somehow changing the arguments used to build crtbegin/end in the first place (and add -mcmodel=kernel/large to it).

Regards,
John.

Posted: **Sat Aug 02, 2014 2:53 pm**

jnc100 wrote:I don't think its possible to have crtbegin/crtend linked anywhere outside of the first 4 GiB of address space. The issue is that libgcc/crtstuff.c generates lots of code of the form mov eax, label (as imm32). The use of this form, rather than mov rax, label (as imm32), means that the label is not sign-extended to 64-bits by the CPU and so negative values cannot be used. Thus R_X86_64_32 references are used in the crtbegin/end.o files, instead of R_X86_64_32S ones, and the linker rightly complains. I'd imagine this behaviour is due to Linux running user space programs at a low address (and so this isn't an issue for them) and them not using C++ in the kernel.

All I can suggest is either linking crtbegin/end to a low address, or somehow changing the arguments used to build crtbegin/end in the first place (and add -mcmodel=kernel/large to it).

Regards,
John.

Thanks for the info. I will try linking them into my bootstrap code which is at physical address 0x100000. I already have initialize() and finalize() functions which call _init/_fini instead of calling them directly, so in those functions I can subtract the kernel's virtual address 0xFFFFFFFF80000000 to call them. I think. I'll post back here if I get it working or not. I'm currently recompiling my cross-compilers. It looks like there are new files/directories in my cross-compiler directory so I think I did something wrong last time.

[edit] I got it to work by rebuilding my cross-compiler as x86_64-none-elf, building all-gcc as normal, but doing a find-and-replace from "-fPIC" to "-mcmodel=kernel" in {build-dir}/x86_64-none-elf/libgcc/Makefile. Readelf still says the relocations are 32-bit but it links now.

Posted: **Mon Aug 04, 2014 1:22 pm**

Synon wrote:I got it to work by rebuilding my cross-compiler as x86_64-none-elf, building all-gcc as normal, but doing a find-and-replace from "-fPIC" to "-mcmodel=kernel" in {build-dir}/x86_64-none-elf/libgcc/Makefile. Readelf still says the relocations are 32-bit but it links now.

Good work, however bear in mind that you probably want a libgcc linked without mcmodel=kernel for usermode applications, otherwise they could not be linked above +2 GiB. This may of course not be a problem for you. I'd imagine your new 32-bit relocations are signed ones rather than unsigned?

Regards,
John.

OSDev.org

[Solved] Relocation truncated errors with .init and .fini

[Solved] Relocation truncated errors with .init and .fini

Re: Relocation truncated errors with .init and .fini

Re: Relocation truncated errors with .init and .fini

Re: [Solved] Relocation truncated errors with .init and .fin