OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Nov 15, 2018 12:36 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Full C++ Support
PostPosted: Fri Nov 09, 2018 6:22 pm 
Offline

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


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Fri Nov 09, 2018 11:56 pm 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 67
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.


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Sun Nov 11, 2018 11:04 am 
Offline

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


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Sun Nov 11, 2018 11:28 am 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 67
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.


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Sun Nov 11, 2018 1:47 pm 
Offline

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)
  }
}


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Mon Nov 12, 2018 12:05 pm 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 67
****, 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?


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Mon Nov 12, 2018 10:17 pm 
Offline

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?


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Mon Nov 12, 2018 10:52 pm 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 67
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.


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Tue Nov 13, 2018 5:54 pm 
Offline

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


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Wed Nov 14, 2018 6:38 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1334
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.


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Wed Nov 14, 2018 10:00 am 
Offline

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


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Wed Nov 14, 2018 10:12 am 
Offline
Member
Member
User avatar

Joined: Thu Mar 10, 2016 7:35 am
Posts: 151
Location: Lancaster, England, Disunited Kingdom
Content of rdi causing misalignment?


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Wed Nov 14, 2018 10:33 am 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 67
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.


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Wed Nov 14, 2018 12:10 pm 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 67
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.


Top
 Profile  
 
 Post subject: Re: Full C++ Support
PostPosted: Wed Nov 14, 2018 12:54 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1334
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group