Cross compiler issue: no .eh_frame_hdr table will be created

[bradhe]

Hey all,

I'm working on building & running the bare bones example via the cross compiler toolchain configured to target i586. I'm getting the following error and warning, and I'm kind of at the end of my rope on deducing what's going on! Any suggestions welcome.

Relevant output. Am I screwing up the GCC invocation?

Code: Select all

brad@h54:/www/dumbos [master*] $ make
rm -rf bin
rm -rf obj/*.o
mkdir bin
nasm -s -f elf -o obj/loader.o src/loader.s
/usr/local/cross/bin/i586-elf-gcc src/kmain.c src/video.c -o obj/kernel.o -Wall -Wextra -Werror -nostdlib -fno-builtin -nostartfiles -nodefaultlibs
/usr/local/cross/lib/gcc/i586-elf/4.6.3/../../../../i586-elf/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000008048054
/usr/local/cross/bin/i586-elf-ld -T src/linker.ld -o bin/kernel.bin obj/loader.o obj/kernel.o
/usr/local/cross/bin/i586-elf-ld: error in obj/kernel.o(.eh_frame); no .eh_frame_hdr table will be created.

[JamesM]

Hi,

Can guess that you're coding in C++? It looks like your kernel.o object has been compiled with exceptions enabled, but your linker script tells the linker to discard the exception table. Hence why it's warning you.

Compile with -fno-exceptions (and -fno-rtti).

[Solar]

Your call:

Code: Select all

/usr/local/cross/bin/i586-elf-gcc src/kmain.c src/video.c -o obj/kernel.o -Wall -Wextra -Werror -nostdlib -fno-builtin -nostartfiles -nodefaultlibs

Call from the tutorial:

Code: Select all

i586-elf-gcc -o kernel.o -c kernel.c -Wall -Wextra -Werror -nostdlib -fno-builtin -nostartfiles -nodefaultlibs

Find the command line option that the tutorial stated but is not present in your code. If necessary, look up its meaning in the compiler manual. It should be obvious from there.

PS: Regarding the issue JamesM pointed out, be notified that there is a separate C++ Bare Bones. (I didn't look beyond the first error out of habit.)

[xenos]

Wait a second... How does C++ come into the game? I know that .eh_frame smells like C++, but I really wonder where this comes from. All that I can see is a bit of assembly and pure C (gcc is called on a .c file - there is neither an invocation of g++, nor any .cpp here). And if the OP indeed followed the bare bones tutorial, there should be no C++ in his source files either. I'm surprised how ld comes up with a warning related to exception handling...

[bradhe]

Find the command line option that the tutorial stated but is not present in your code. If necessary, look up its meaning in the compiler manual. It should be obvious from there.

PS: Regarding the issue JamesM pointed out, be notified that there is a separate C++ Bare Bones. (I didn't look beyond the first error out of habit.)

Thanks for the prompt reply guys. I was trying to get GCC to spit out one obj file, and then link that obj file with The obj produced by nasm via ld. What is standard practice for that? Multiple obj files?

[bradhe]

Wait a second... How does C++ come into the game? I know that .eh_frame smells like C++, but I really wonder where this comes from. All that I can see is a bit of assembly and pure C (gcc is called on a .c file - there is neither an invocation of g++, nor any .cpp here). And if the OP indeed followed the bare bones tutorial, there should be no C++ in his source files either. I'm surprised how ld comes up with a warning related to exception handling...

Oh yeah, no C++ here, by the way...

[Combuster]

Multiple obj files?

Yes.

[Solar]

I was trying to get GCC to spit out one obj file...

1) Don't. Call GCC seperate for each translation unit (.c file).

2) Use "-c" to get an object file. By omitting that option, you're telling GCC to generate an executable...

[gerryg400]

You can get this error if your GCC is not built correctly. I'm not sure about the cross-compiler in the tutorial but for a long time I had this issue. Eventually modifying this line in my config.gcc solved it. My recollection is that it applies mainly to 64 bit cross-compilers. I'm not suggesting that it's your problem but offer it here in case others are looking for a solution.

Code: Select all

+	tmake_file="${tmake_file} i386/t-i386elf t-svr4 i386/t-crtstuff"

Adding the i386/t-crtstuff was the solution.

[Solar]

Check this GCC ticket regarding the meaning of t-crtstuff.

[brain]

When I've had this issue in the past (undefined symbol _start) I've managed to get around it with the gcc -freestanding flag. note, this is kind of unrelated to the eh_frame errors.

[gerryg400]

Check this GCC ticket regarding the meaning of t-crtstuff.

That's the one.

[Jezze]

I had this issue as well. I thought it was because I built gcc using --enable-languages=c and that made it complain about missing eh_frame.

EDIT: Sorry not same error.

[invalid]

I'm confused after what I've read here. My cross-compiler has only C enabled, but it generates eh_frame sections anyway (discarded by linker). Is this wrong?

[JamesM]

Wait a second... How does C++ come into the game? I know that .eh_frame smells like C++, but I really wonder where this comes from. All that I can see is a bit of assembly and pure C (gcc is called on a .c file - there is neither an invocation of g++, nor any .cpp here). And if the OP indeed followed the bare bones tutorial, there should be no C++ in his source files either. I'm surprised how ld comes up with a warning related to exception handling...

Interestingly, I thought the gcc compiler driver could compile .c files as C++ without -x c++ - I was wrong, apparently it requires -x c++.

I didn't notice the lack of "-c" on his command line, and that made me think gcc was compiling kernel.c as C++.