Full C++ Support

midonator1305 · **Joined:** Mon Oct 08, 2018 11:47 am **Posts:** 7

Hello,

I am writing a kernel in c++ and I wanted to use libsupc++. After some struggling I managed to get g++ to compile.
I fixed all the missing symbols and compiled but now I am getting a new error

Code:

x86_64-elf-gcc -ffreestanding -nostdlib -z max-page-size=0x1000 -T linker.ld -g -o vmmse obj/gdt.o obj/common/panic.o obj/common/printf.o obj/common/stacktrace.o obj/loader.o obj/drivers/keyboard.o obj/drivers/syscallintr.o obj/drivers/mouse.o obj/kernel.o obj/multiboot2.o obj/gdtr.o obj/loader_feat.o obj/libupcxx.o obj/libc/string.o obj/hw/interruptstubs.o obj/hw/ports.o obj/hw/interrupts.o obj/pmm.o -lgcc -lsupc++
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o): in function `__gxx_personality_v0':
/home/msee/src/build-gcc/x86_64-elf/libstdc++-v3/libsupc++/../../../../gcc-8.2.0/libstdc++-v3/libsupc++/eh_personality.cc:558:(.text.__gxx_personality_v0+0x32d): relocation truncated to fit: R_X86_64_32 against symbol `typeinfo for __cxxabiv1::__forced_unwind' defined in .rodata._ZTIN10__cxxabiv115__forced_unwindE[typeinfo for __cxxabiv1::__forced_unwind] section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_exception.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /home/msee/src/build-gcc/x86_64-elf/libstdc++-v3/libsupc++/../../../../gcc-8.2.0/libstdc++-v3/libsupc++/eh_personality.cc:564:(.text.__gxx_personality_v0+0x341): relocation truncated to fit: R_X86_64_32 against symbol `typeinfo for __cxxabiv1::__foreign_exception' defined in .rodata._ZTIN10__cxxabiv119__foreign_exceptionE[typeinfo for __cxxabiv1::__foreign_exception] section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_exception.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o): in function `__cxa_call_unexpected':
/home/msee/src/build-gcc/x86_64-elf/libstdc++-v3/libsupc++/../../../../gcc-8.2.0/libstdc++-v3/libsupc++/eh_personality.cc:782:(.text.unlikely.__cxa_call_unexpected+0x45): relocation truncated to fit: R_X86_64_32 against symbol `typeinfo for std::bad_exception' defined in .rodata._ZTISt13bad_exception[typeinfo for std::bad_exception] section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_exception.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /home/msee/src/build-gcc/x86_64-elf/libstdc++-v3/libsupc++/../../../../gcc-8.2.0/libstdc++-v3/libsupc++/eh_personality.cc:783:(.text.unlikely.__cxa_call_unexpected+0x89): relocation truncated to fit: R_X86_64_32 against symbol `std::bad_exception::~bad_exception()' defined in .text._ZNSt13bad_exceptionD2Ev section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_exception.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /home/msee/src/build-gcc/x86_64-elf/libstdc++-v3/libsupc++/../../../../gcc-8.2.0/libstdc++-v3/libsupc++/eh_personality.cc:783:(.text.unlikely.__cxa_call_unexpected+0x8e): relocation truncated to fit: R_X86_64_32 against symbol `typeinfo for std::bad_exception' defined in .rodata._ZTISt13bad_exception[typeinfo for std::bad_exception] section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_exception.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x15b): relocation truncated to fit: R_X86_64_32 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x179): relocation truncated to fit: R_X86_64_32 against `.gcc_except_table.__gxx_personality_v0'
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x1cb): relocation truncated to fit: R_X86_64_32 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x1f9): relocation truncated to fit: R_X86_64_32 against `.gcc_except_table.__gxx_personality_v0'
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x211): relocation truncated to fit: R_X86_64_32 against `.gcc_except_table.__cxa_call_unexpected'
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x23f): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
Makefile:33: recipe for target 'vmmse' failed
make: *** [vmmse] Error 1

Is it a problem with the compiler or linking?
or did I mess something up in the code

I used newlib to compile if that matters

nullplan · **Joined:** Wed Aug 30, 2017 8:24 am **Posts:** 1604

midonator1305 wrote:

I am writing a kernel in c++

Well, there's your problem, lady! (Or mister. Or intermediate.)

midonator1305 wrote:

Code:

[...]relocation truncated to fit[...]

Is it a problem with the compiler or linking?
or did I mess something up in the code

Compilation and linker script do not fit. For a kernel, I would suggest compiling all code with "-mcmodel=kernel". That includes all libraries, such as libgcc and libsupc++. Then the linker script can link the kernel above the -2GB line. And while you're at it, remember "-mno-red-zone".

The error message means that they only allocated 4 bytes of space for a pointer, and now the symbol is outside the range that supports that. That is a common symptom of using the wrong load address (0xffff800000000000 instead of 0xffffffff80000000) with code generated with any model except the large one. But the large model is largely overkill if your program won't exceed 2GB is size.

midonator1305 · **Joined:** Mon Oct 08, 2018 11:47 am **Posts:** 7

nullplan wrote:

midonator1305 wrote:

I am writing a kernel in c++

Well, there's your problem, lady! (Or mister. Or intermediate.)

now I see why haha

nullplan wrote:

Compilation and linker script do not fit. For a kernel, I would suggest compiling all code with "-mcmodel=kernel". That includes all libraries, such as libgcc and libsupc++. Then the linker script can link the kernel above the -2GB line. And while you're at it, remember "-mno-red-zone".

The error message means that they only allocated 4 bytes of space for a pointer, and now the symbol is outside the range that supports that. That is a common symptom of using the wrong load address (0xffff800000000000 instead of 0xffffffff80000000) with code generated with any model except the large one. But the large model is largely overkill if your program won't exceed 2GB is size.

I attempted this but gcc and newlib don't seem to like -mcmodel=kernel.

Code:

../gcc-8.2.0/configure --target=$TARGET --prefix=$PREFIX --disable-nls --enable-languages=c,c++ --without-headers --disable-hosted-libstdcxx CFLAGS=-mcmodel=kernel
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-elf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /bin/sed
checking for gawk... gawk
checking for libatomic support... no
checking for libitm support... no
checking for libsanitizer support... no
checking for libvtv support... no
checking for libmpx support... no
checking for libhsail-rt support... no
checking for gcc... gcc
checking for C compiler default output file name... 
configure: error: in `/home/midoe/src/build-gcc':
configure: error: C compiler cannot create executables
See `config.log' for more details.

but it doesn't mind -mcmodel=large
so I am not really sure what to do

nullplan · **Joined:** Wed Aug 30, 2017 8:24 am **Posts:** 1604

Close but no cigar. according to the wiki (https://wiki.osdev.org/Building_libgcc_ ... l%3Dkernel), you were supposed to use CFLAGS_FOR_TARGET during the "make all-target-libgcc" step of the process.

midonator1305 · **Joined:** Mon Oct 08, 2018 11:47 am **Posts:** 7

nullplan wrote:

Close but no cigar. according to the wiki (https://wiki.osdev.org/Building_libgcc_ ... l%3Dkernel), you were supposed to use CFLAGS_FOR_TARGET during the "make all-target-libgcc" step of the process.

So I recompiled and it seemed to have build. I built "all-target-libstdc++-v3" using the same command as "all-target-libgcc" and it built. I recompiled my kernel and

Code:

x86_64-elf-g++ -ffreestanding -nostdlib -z max-page-size=0x1000 -T linker.ld -g -o vmmido obj/gdt.o obj/fs/msdospart.o obj/fs/fat.o obj/cxa_guard.o obj/common/panic.o obj/common/printf.o obj/common/stacktrace.o obj/loader.o obj/drivers/keyboard.o obj/drivers/ata.o obj/drivers/syscallintr.o obj/drivers/mouse.o obj/kernel.o obj/multiboot2.o obj/gdtr.o obj/loader_feat.o obj/libupcxx.o obj/libc/AtomicLong.o obj/libc/string.o obj/libc/SHA256.o obj/libc/Random.o obj/hw/interruptstubs.o obj/hw/ports.o obj/hw/interrupts.o obj/pmm.o -lgcc -lsupc++
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o): in function `__gxx_personality_v0':
/home/midoe/src/build-gcc/x86_64-elf/libstdc++-v3/libsupc++/../../../../gcc-8.2.0/libstdc++-v3/libsupc++/eh_personality.cc:558:(.text.__gxx_personality_v0+0x32d): relocation truncated to fit: R_X86_64_32 against symbol `typeinfo for __cxxabiv1::__forced_unwind' defined in .rodata._ZTIN10__cxxabiv115__forced_unwindE[typeinfo for __cxxabiv1::__forced_unwind] section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_exception.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /home/midoe/src/build-gcc/x86_64-elf/libstdc++-v3/libsupc++/../../../../gcc-8.2.0/libstdc++-v3/libsupc++/eh_personality.cc:564:(.text.__gxx_personality_v0+0x341): relocation truncated to fit: R_X86_64_32 against symbol `typeinfo for __cxxabiv1::__foreign_exception' defined in .rodata._ZTIN10__cxxabiv119__foreign_exceptionE[typeinfo for __cxxabiv1::__foreign_exception] section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_exception.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o): in function `__cxa_call_unexpected':
/home/midoe/src/build-gcc/x86_64-elf/libstdc++-v3/libsupc++/../../../../gcc-8.2.0/libstdc++-v3/libsupc++/eh_personality.cc:782:(.text.unlikely.__cxa_call_unexpected+0x45): relocation truncated to fit: R_X86_64_32 against symbol `typeinfo for std::bad_exception' defined in .rodata._ZTISt13bad_exception[typeinfo for std::bad_exception] section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_exception.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /home/midoe/src/build-gcc/x86_64-elf/libstdc++-v3/libsupc++/../../../../gcc-8.2.0/libstdc++-v3/libsupc++/eh_personality.cc:783:(.text.unlikely.__cxa_call_unexpected+0x89): relocation truncated to fit: R_X86_64_32 against symbol `std::bad_exception::~bad_exception()' defined in .text._ZNSt13bad_exceptionD2Ev section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_exception.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /home/midoe/src/build-gcc/x86_64-elf/libstdc++-v3/libsupc++/../../../../gcc-8.2.0/libstdc++-v3/libsupc++/eh_personality.cc:783:(.text.unlikely.__cxa_call_unexpected+0x8e): relocation truncated to fit: R_X86_64_32 against symbol `typeinfo for std::bad_exception' defined in .rodata._ZTISt13bad_exception[typeinfo for std::bad_exception] section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_exception.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x15b): relocation truncated to fit: R_X86_64_32 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x179): relocation truncated to fit: R_X86_64_32 against `.gcc_except_table.__gxx_personality_v0'
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x1cb): relocation truncated to fit: R_X86_64_32 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o)
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x1f9): relocation truncated to fit: R_X86_64_32 against `.gcc_except_table.__gxx_personality_v0'
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x211): relocation truncated to fit: R_X86_64_32 against `.gcc_except_table.__cxa_call_unexpected'
/usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/bin/ld: /usr/local/cross/lib/gcc/x86_64-elf/8.2.0/../../../../x86_64-elf/lib/libsupc++.a(eh_personality.o):(.eh_frame+0x23f): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
Makefile:33: recipe for target 'vmmido' failed
make: *** [vmmido] Error 1

Same issue I think.

maybe the linker script is wrong?

Code:

OUTPUT_FORMAT(elf64-x86-64)
ENTRY(start)

PAGE_SIZE  = 0x1000;
KERNEL_VMA = 0xFFFFFFFF80000000;
UPPER_MEM  = 0x100000;

SECTIONS
{
  . = UPPER_MEM;
  _start = . + KERNEL_VMA;

  .init :
  {
    *(.initl)
  }

  . += KERNEL_VMA;

  .text ALIGN(PAGE_SIZE) : AT(ADDR(.text) - KERNEL_VMA)
  {
    *(.inith)
    *(.text*)
    *(.gnu.linkonce.t*)
  }

  .data ALIGN(PAGE_SIZE) : AT(ADDR(.data) - KERNEL_VMA)
  {
    *(.data)
    *(.gnu.linkonce.d*)
  }

  .rodata ALIGN(PAGE_SIZE) : AT(ADDR(.rodata) - KERNEL_VMA)
  {
     start_ctors = .;
     *(SORT(.ctors*))  /* Note the "SORT" */
     end_ctors = .;

     start_dtors = .;
     *(SORT(.dtors*))
     end_dtors = .;

     *(.rodata*)
     *(.gnu.linkonce.r*)
  }

  .eh_frame_hdr ALIGN(PAGE_SIZE) : AT(ADDR(.eh_frame_hdr) - KERNEL_VMA)
  {
    *(.eh_frame_hdr*)
  }

  .eh_frame ALIGN(PAGE_SIZE) : AT(ADDR(.eh_frame) - KERNEL_VMA)
  {
    start_eh_frame = .;
    *(.eh_frame*)
  }

  .gcc_except_table ALIGN(PAGE_SIZE) : AT(ADDR(.gcc_except_table) - KERNEL_VMA)
  {
    *(.gcc_except_table*)
  }

  .bss ALIGN(PAGE_SIZE) : AT(ADDR(.bss) - KERNEL_VMA)
  {
    *(COMMON)
    *(.bss)
    *(.gnu.linkonce.b*)
  }

  _end = .;

  /DISCARD/ :
  {
    *(.comment)
  }
}

nullplan · **Joined:** Wed Aug 30, 2017 8:24 am **Posts:** 1604

****, so I can't just throw wiki pages at you until the problem goes away. :wink:

Well, let's go back to form. Why does the error occur? R_X86_64_32 is the zero-extended 32 bit relocation type for AMD64. Obviously, -2GB is outside of the range for such a type, but why is R_X86_64_32S not being employed (that would be the sign-extended 32 bit relocation type)? The relocation type is set by the assembler, based on the input it got from the compiler. So I'll have to look into the gas and gcc source codes. Fun times ahead! And the relocations actually are in libsupc++. Is it possible that libsupc++ has a different syntax for CFLAGS for the target? Does anyone know?

midonator1305 · **Joined:** Mon Oct 08, 2018 11:47 am **Posts:** 7

nullplan wrote:

So I'll have to look into the gas and gcc source codes. Fun times ahead!

Haha I wish you luck

Here’s an update I decided to compile everything again. I set some environmental variables this time to make sure I didn’t miss something. I set “CFLAGS” “CXXFLAGS” “CFLAGS_FOR_TARGET” and “CXXFLAGS_FOR_TARGET” all to “-mcmodel=large -mno-red-zone”. Large is a bit excessive as you said but it should link to any address. I built binutils, gcc but without doing “make all-target-libstdc++-v3”, newlib and finally rebuilt gcc but included the “libstdc++-v3” and it built

It finally links but than it calls abort. It attempted to call malloc in the global construction which was not initiated yet. After fixing that it ran correctly. I read on the wiki (https://wiki.osdev.org/Libsupcxx#Full_C.2B.2B_Runtime_Support_Using_libgcc_And_libsupc.2B.2B)

Quote:

To make use of exception handling, you also have to tell libsupc++ where the .eh_frame section begins. Before you throw any exception: <verbatim>__register_frame(address_of_eh_frames); </verbatim>.

Quote:

You also need to provide __register_frame() (or call the function provided by libgcc with the start of your .eh_frame section), void *__dso_handle;, __cxa_atexit() and __cxa_finalize (again see C++).

I do not understand this. It says call the function provided by libgcc. Which one is it? I’ve seen __register_frame_info and __register_frame so are those it? also what are those last 3 functions?

nullplan · **Joined:** Wed Aug 30, 2017 8:24 am **Posts:** 1604

midonator1305 wrote:

nullplan wrote:

So I'll have to look into the gas and gcc source codes. Fun times ahead!

Haha I wish you luck

Here’s an update I decided to compile everything again. I set some environmental variables this time to make sure I didn’t miss something. I set “CFLAGS” “CXXFLAGS” “CFLAGS_FOR_TARGET” and “CXXFLAGS_FOR_TARGET” all to “-mcmodel=large -mno-red-zone”. Large is a bit excessive as you said but it should link to any address. I built binutils, gcc but without doing “make all-target-libstdc++-v3”, newlib and finally rebuilt gcc but included the “libstdc++-v3” and it built

Man, if you could hear me swearing right now. These source codes are like staring into the sun. Now I need my eyes looked at...

Anyway, I suppose the CXXFLAGS_FOR_TARGET thing was what you were missing. Explains why the linker only complained about libsupc++, and not libgcc.

midonator1305 wrote:

It finally links but than it calls abort. It attempted to call malloc in the global construction which was not initiated yet. After fixing that it ran correctly. I read on the wiki (https://wiki.osdev.org/Libsupcxx#Full_C.2B.2B_Runtime_Support_Using_libgcc_And_libsupc.2B.2B)

Quote:

To make use of exception handling, you also have to tell libsupc++ where the .eh_frame section begins. Before you throw any exception: <verbatim>__register_frame(address_of_eh_frames); </verbatim>.

Quote:

You also need to provide __register_frame() (or call the function provided by libgcc with the start of your .eh_frame section), void *__dso_handle;, __cxa_atexit() and __cxa_finalize (again see C++).

I do not understand this. It says call the function provided by libgcc. Which one is it? I’ve seen __register_frame_info and __register_frame so are those it? also what are those last 3 functions?

__register_frame() is indeed provided by libgcc. It wraps __register_frame_info(). If you have a working malloc(), I would just call __register_frame().

Those last three implement the atexit() stuff for a dynamic shared object. What they're supposed to do is: __dso_handle is supposed to point to the most recently loaded module, __cxa_atexit() is supposed to register exit handlers for a DSO, and __cxa_finalize() is supposed to run all the exit handlers for a certain DSO.

Since a kernel never exits, and you probably don't have loadable modules right at the start, I would just declare __dso_handle, set it to 0 and never touch it again. __cxa_atexit() is a dummy function that always returns success, in order not to disturb the C++ compiler, and __cxa_finalize() panics, because you should never get there.

midonator1305 · **Joined:** Mon Oct 08, 2018 11:47 am **Posts:** 7

nullplan wrote:

__register_frame() is indeed provided by libgcc. It wraps __register_frame_info(). If you have a working malloc(), I would just call __register_frame().

Those last three implement the atexit() stuff for a dynamic shared object. What they're supposed to do is: __dso_handle is supposed to point to the most recently loaded module, __cxa_atexit() is supposed to register exit handlers for a DSO, and __cxa_finalize() is supposed to run all the exit handlers for a certain DSO.

Since a kernel never exits, and you probably don't have loadable modules right at the start, I would just declare __dso_handle, set it to 0 and never touch it again. __cxa_atexit() is a dummy function that always returns success, in order not to disturb the C++ compiler, and __cxa_finalize() panics, because you should never get there.

I see now, Thanks

I tested it out by simply throwing an int and catching it.
I tested on qemu and it works! but not on virtual box or bochs for some reason.
It sends interrupt 0x0d (General Protection Fault if I remember correctly) with a error code of 0
not really sure why but it does this.

the exact output of bochs is

Code:

00017880458i[BIOS  ] Booting from 07c0:0000
00091900680e[CPU0  ] read_linear_xmmword_aligned(): #GP misaligned access
00092241499i[CPU0  ] WARNING: HLT instruction with IF=0!

I traced it back to an instruction (at 0xffffffff80116f58 if that matters)

Code:

movdqa xmm0, dqword ptr ds:[rdi]

(rdi was 0xFFFFFFFF8013713A at the time)
I am not sure why this happens. every time it looks like its about to work it decides otherwise

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5137

Is your stack correctly 16-byte aligned?

Which function contains the faulting instruction? You might be able to narrow down the source of the misaligned pointer by which function is using it.

midonator1305 · **Joined:** Mon Oct 08, 2018 11:47 am **Posts:** 7

Octocontrabass wrote:

Is your stack correctly 16-byte aligned?

It is aligned as far as I know

Octocontrabass wrote:

Which function contains the faulting instruction? You might be able to narrow down the source of the misaligned pointer by which function is using it.

The addresses shifted a bit but I got it to 0xffffffff80116ed8
Using objdump I searched for the address and the instructions are pretty similar

Code:

ffffffff80116fd8: movdqa xmm0,XMMWORD PTR [rdi]

so if I didn't make a mistake the problematic instructions are in uw_update_context_1

MichaelFarthing · **Posted:** Wed Nov 14, 2018 10:12 am

Content of rdi causing misalignment?

nullplan · **Joined:** Wed Aug 30, 2017 8:24 am **Posts:** 1604

midonator1305 wrote:

I traced it back to an instruction (at 0xffffffff80116f58 if that matters)

Code:

movdqa xmm0, dqword ptr ds:[rdi]

(rdi was 0xFFFFFFFF8013713A at the time)
I am not sure why this happens. every time it looks like its about to work it decides otherwise

The instruction is called "movdqa". And the a at the end stands for what? And what is 0xffffffff8013713a not?

Spoiler: The a stands for aligned. SSE registers are 16 bytes in size, so the address must be divisible by 16. Which is easy to see in hex, it must end in 0. And A is not 0.

Actually, wait a minute. Did you set up SSE? Because kernel mode SSE is generally a bad idea (unless you want to save SSE regs along with the other ones on every context switch). So, if you did not write this movdqa instruction, then gcc did. So you might need to recompile your libs again, this time with "-mno-sse" in the CFLAGS. And if that is needed, maybe all the other ones are needed as well.

Maybe we should write a feature request to the GCC people for a switch that makes GCC not do things that break unassuming code.

I cannot find a single reference to movdqa in the GCC source code, but I did find references to the intrinsic form in libstdc++. And that code depends on SSE2 at compile time. It's used in the PRNG, though. Oh, and having searched through the assembly files, I can now see that libffi is using SSE.

nullplan · **Joined:** Wed Aug 30, 2017 8:24 am **Posts:** 1604

GCC man page wrote:

-mgeneral-regs-only
Generate code that uses only the general-purpose registers. This prevents the compiler from using floating-point, vector, mask and bound registers.

I guess we have a new flag to add to all the "Make your own GCC cross compiler" wiki pages.

Octocontrabass · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 5137

midonator1305 wrote:

The addresses shifted a bit but I got it to 0xffffffff80116ed8
Using objdump I searched for the address and the instructions are pretty similar

Code:

ffffffff80116fd8: movdqa xmm0,XMMWORD PTR [rdi]

so if I didn't make a mistake the problematic instructions are in uw_update_context_1

The addresses shouldn't shift at all. Your code should be running at the exact addresses specified in the elf (and displayed by objdump).

Assuming the faulting instruction really is in uw_update_context_1, that means the fault happens during the frame unwinding part of exception handling. Since the frames in question are on the stack, this suggests that your stack is misaligned as well.

If you want to use lazy context switching in your kernel, you'll need to adjust your compiler to avoid using FP and SIMD registers. However, lazy context switching is a security vulnerability in many Intel CPUs, so you might instead choose to leave SIMD enabled and gain the convenience of having floating-point math in your kernel.

OSDev.org

Full C++ Support

Who is online