OSDev.org

Hi All
once more i return to this fine board to ask another question.

I decided yesterday that it was too much hassle to sort out the development environment on WinXP and i really wanted to get started on the project- so i duel-booted Redhat onto my other WinXP machine. So now i've changed development platforms...wooooo! Which is good since i love Linux and I had forgotten how much i loved it for a long time.

Now i got NASM and GCC being friendly to one another and enjoying a file output that is common to LD.

I almost went knee-deep in excrement, but luckily read in a post, on this very forum, about the prefixing of '_' in the asm loader only being needed in the Windows GCC ports. Phew!

Anyway, i have no idea why this is happening:
i am using all the right flags on GCC, the same i was using when using MinGW, when compiling my source:
-ffreestanding -nostdlib -fno-builtin -fno-rtti -fno-exceptions
But when i come to link my source into a beautiful flat binary file i get this nefarious error:
video.o [...] Undefined Reference to __builtin_delete

Ouch!

but surely the "-fno-builtin" flag tells it to avoid all builtin functions?

why, pray-tell, does it feel the need to hinder my progress in such a savage manner?

Are there any flags i have not used that should be used for a Linux GCC compile?
I'm not being lazy by just asking this without looking- i have spent a while looking for a solution but have not yet come upon a method of resolving it.

I thank thee for any assistance,
-Charlie

Well first of all, redhat will always bow down to Gentoo. You shouldn't have to fight packages to install, instead you should just type "emerge x" like we Gentoo users. I won't talk about that for long.

Anyway, here are the flags I use for a Linux GCC compile and an OS
-ffreestanding -nostdlib -fno-leading-underscore -Wall -Iinclude

so I'd suggest you try those, those that have worked for me so elegantly. Of course, the -fno-leading-underscore might not jive with what you've done with the source, but that lends a little more cross compatibility with compiling...

ok, i tried those flags and still no cigar.
I am still getting 'Video.o [...] Undefined Reference to __builtin_delete'

Oh, i'm having a quick looky at gentoo- it looks quite interesting

if anyone else has any suggestions...

-Charlie

Hang on-
I think i just worked something out...[Mind cogs start revolving]...It is saying that the reference is in "Video::~Video()"
Is it because i am using a class here that i am getting problems? I am still following Part one of the 'Writing a Kernel in C++". My code is exactly the same as in that tutorial inlcuding the linker script.

Oh, you're using C++, well I guess I shouldn't have said anything then.

For GCC 2.x, __builtin_delete() is the mangled name for one of these (I don't remember which one):
So, you need to implement one of these functions. "-fno-builtin" won't help you here.

http://my.execpc.com/~geezer/osd/cpp/index.htm#builtin

Video::~Video() is called when an object of class Video goes out of scope. The primary job of the destructor is to deallocate memory allocated by the constructor... this is handled by __builtin_new and __builtin_delete unless you have overloaded operator new() and operator delete().

Since, as a kernel developer, you are compiling a freestanding binary, those two builtins aren't defined for your binary.

The error is not (really) in the compiler options. The compiler must call some function for deallocating memory. The solution is to overload operator new() and operator delete() with implementations of your own.

But judging from the class name, I'd daresay you need only one object of that type... in which case you might want to consider using a static (global) object. That would mean the storage is allocated in the binary, initialized by your startup code (see the FAQ on C++ kernel building for an example), and never deallocated.

Solar wrote: That would mean the storage is allocated in the binary, initialized by your startup code (see the FAQ on C++ kernel building for an example), and never deallocated.

If it's never deallocated, do you still need a destructor / does gcc provide one when you don't?

Candy wrote: If it's never deallocated, do you still need a destructor / does gcc provide one when you don't?

In ELF format at least, when you use static objects, gcc generates one (or more) code section(s) .ctor*, containing an array of pointers into the respective constructors, and one (or more) code section(s) .dtor*, containing an array of pointers into the respective destructors.

It is the task of the runtime environment to call these prior to entering main().

Since we have neither a "real" main() nor a runtime environment, you have to call the constructors yourself. Whether you call the destructors or not is up to you.

one thing i would wonder is "do you need to delete the Video instance ?" If you don't, don't write a destructor and make your object global ... that way __builtin_delete will never be called.

Also, offering a delete() operator should prevent the compiler to fall back on the builtin one

Pype.Clicker wrote: one thing i would wonder is "do you need to delete the Video instance ?" If you don't, don't write a destructor and make your object global ... that way __builtin_delete will never be called.

Also, offering a delete() operator should prevent the compiler to fall back on the builtin one

The point was, if I don't provide a destructor, will GCC automatically create one (with its own builtin_destructor or something I really don't need) and put it in .dtor? If so, the compile still goes wrong, even though I never call the function (also, it puts trash in my kernel! cut that out!)

Candy wrote: The point was, if I don't provide a destructor, will GCC automatically create one (with its own builtin_destructor or something I really don't need) and put it in .dtor? If so, the compile still goes wrong, even though I never call the function (also, it puts trash in my kernel! cut that out!)

Well, for one you could just leave out .dtor* from your linker script (so it doesn't get linked into the kernel binary). And, calling global constructors / destructors is completely up to the environment, so there will be no "implicit calls".

And then, a basic rule of C++ design: If you don't have anything special to do in it, don't write a destructor. If you don't have a new() (or other dynamic ressource allocation) in your constructor, you don't need a destructor.

hmm ... okay, so even for global objects, C++ feels the need for destructing objects when 'main' stops ...

Would it be wishable to strip out the .dtor list ? So that you no longer need a __builtin_delete in any way ...

The other trick i would be trying would be to offer a Permanent or Singleton base class that would define a 'delete' operator that does nothing so that any class that shouldn't be 'deleted' would inherit the Permanent class ...

Solar wrote:

Candy wrote: The point was, if I don't provide a destructor, will GCC automatically create one (with its own builtin_destructor or something I really don't need) and put it in .dtor? If so, the compile still goes wrong, even though I never call the function (also, it puts trash in my kernel! cut that out!)

Well, for one you could just leave out .dtor* from your linker script (so it doesn't get linked into the kernel binary). And, calling global constructors / destructors is completely up to the environment, so there will be no "implicit calls".

And then, a basic rule of C++ design: If you don't have anything special to do in it, don't write a destructor. If you don't have a new() (or other dynamic ressource allocation) in your constructor, you don't need a destructor.

I know about that. Still, you didn't answer

If I don't create a destructor for class X, GCC will. The file will then contain a destructor in .text, and a call to it in .dtor. I can strip out both using very complex commands or programs, but that's not the point

I assume GCC does whatever is physically possible whenever I'm not guiding it a full 100%. It can, thus, in my view, include a call to __cxa_something_destroyed(void *what) in its destructor. I really don't want this. Does it do that?

Candy wrote: Still, you didn't answer

I just realized myself that my post was short of the mark. :-\

I really don't want this. Does it do that?

Implementation defined. Means, take a piece of minimal code that sculpts the issue, compile it to your target format (since the format is important too), dissassemble...