Can I avoid linking with libstdc++ / libsupc++?

[t0mb0la]

Still actively working on Altimit. I've been implementing some code from emoon (init.cpp) mainly in an attempt to figure out why memory allocated and freed remains locked; still hitting a brick wall on this one.
Anyway, thought it would be nice to remove '-lsupc++' from the Altimit Makefile (init.cpp has the operators / functions I need) but it fails to link with following errors:

snip...

Code: Select all

abstractFS.o(.gnu.linkonce.d._ZTI9altimitIO+0x0): In function `hddIO::hddIO[not-in-charge]()':
abstractFS.cpp: undefined reference to `vtable for __cxxabiv1::__class_type_info'
abstractFS.o(.gnu.linkonce.d._ZTI5hddIO+0x0):abstractFS.cpp: undefined reference to `vtable for __cxxabiv1::__si_class_type_info'

snip...

Is this something I could overcome by adding some more functionality to init.cpp or do I just have to accept linking with libsupc++ / libstdc++?

As for the memory, I'm running out of things to try. Looking at the log of all my allocations / deallocations it seems that everything is being done cleanly, just the freed memory is never returned to the heap. Short of writing my own memory management, I can't think of anything else to try.
I am treating the memory much like a stack, i.e. the last allocated is first to be freed. The output log is quite long, so I won't paste it in here. I'm not sure it gives any clues to what is going wrong anyway, but for those interested here is a link http://home.comcast.net/~tomhawcroft/output.txt

[Guest]

Unless I am misunderstanding you situation, everything sounds right to me.
It is normal in C/C++ memory management that memory allocated from the
system's free memory pool never gets returned to the system, but remains
managed under the programs own individual pool.

So if you are wondering why memory is never returned to the system,
you are seeing situation normal. If however, you are freeing memory
back to the programs own individual memory pool, and then requesting
a memory block of the same size, and see that the freed blocks never
get reused, then there is a memory leak in the standard library somplace.

Gorim

[pixel]

You theorically can remove libstdc++. Now it's quite hard to write any useful piece of code which won't hit some symbol contained in it. You are actually asking it some typeinfo classes.

Now, libstdc++ shouldn't be toooo heavy, if you keep away from some nasty STL parts which are requiring newlib (that is, usually, streams)


For memory, I'd say you should do the following design if you want to put on your own memory management:

Write a "Base" classe, with something like this:

Code: Select all

class Base {
  public:
    static char * strdup(const char * s);
    static void * malloc(ssize_t s);
    static void * realloc(void * p, size_t s);
    static void * calloc(size_t n, size_t s);
    void * operator new(size_t s);
    void * operator new(size_t s, void * p);
    template <class T>
    static void free&#40;T *& p&#41; &#123;
        /* I write only this one, a bit weired */
        void * t = &#40;void *&#41; p;
        my_free&#40;t&#41;;
        p = 0; /* yay */
    &#125;
    void operator delete&#40;void *p&#41;;
&#125;;

Now, make all your classes derivate to that base class, and write all the code you want like my_free, my_malloc, etc ..., in order to handle yourself the memory

[chp]

Working without libstdc++ is quite simple actually. To accomplish this, do the following:

1)
Write your own new, delete, new[] and delete[]. They can map directly to malloc and free.

Code: Select all

void* operator new(size_t size) { return malloc(size); }
void* operator new[](size_t size) { return malloc(size); }
void operator delete(void* p) { free(p); }
void operator delete[](void* p) { free(p); }

2)
Compile your code using -fno-exceptions and -fno-rtti.

3)
You need the following function declared somewhere to resolve the function that is called when a pure virtual call is encountered:

Code: Select all

extern "C"
{
 void __cxa_pure_virtual() {}
}

That should be it. Stay away from things like STL and you should be OK.

[t0mb0la]

Wanted to say thanks for all the tips guys.

I'm still looking into the memory allocation issue; still running out of memory after repeating the new / delete cycles often enough.

Just to clarify, init.cpp (the code emoon passed onto me), has the "new, new[], delete, delete[] operators defined in it, as well as the __cxa_pure_virtual".

I didn't have the compile options -fno-exceptions or fno-rtti, so I quickly added those, removed -lsupc++ from LDFLAGS ans sure enough it compiled and linked without errors. Nice tip chp. :)

I guess I was really hoping that removing libstdc++/libsupc++ would fix whatever the problem is I'm having with malloc/free. If only it was that simple.

Maybe what I should really be asking, is why isn't the first address I get from memalign( 64, 1228864 ) at the start of the heap (the address returned from ps2_sbrk(0);)? As looking at the output.txt, 0x184f00 is the only address which seems to be allocated/freed and subsequently reused.

Well, thanks again. I'm going to sleep on it.

[mrbrown]

Hmm, something seems a bit off in malloc(). The _heap_mem_fit() routine must not be finding gaps properly.

To get things going you may want to link with newlib's malloc() (Doug Lea's malloc which you can also find online).