Re: Libraries for exception handling?

[Guy Harrison]

David Olsson wrote:

> Guy Harrison <swamp-DEL-dog@ntlworld.com> wrote in message
> news:<lngric.mh61.ln@sd-if.swampdog>...
>> David Olsson wrote:
>> 
>> > Maurizio Loreti <mlo@foobar.it> wrote in message
>> > news:<rmu0tr8zto.fsf@mlinux.pd.infn.it>...
>> >> You invoke g++, not gcc, in the command line --- right?
>> > 
>> > Yes I invoke g++, but it really wouldn't matter if I invoked gcc since
>> > I explicitly use ld to link and don't link with any of the default
>> > libararies (like -lstdc++ and -lsupc++) since, in the case of
>> > -lstdc++, I don't use any of its functonalities (at least not
>> > explicitly) and should thus not require it(?), and, in the case of
>> > -lsupc++, it makes use of malloc() and free() which defintately is off
>> > limits on this platform.
>> 
>> Why?
>>  
>> > What I really need is a way to be able to use exception handling (if I
>> > remove all exceptions from the code, the linking works just fine)
>> > without having to link with a library that uses malloc() and free().
>> > Any ideas?
>> 
>> Implement your own malloc.
> 
> I am currently implementing my own malloc and free. I link with
> libiberty.a instead if libc.a. As libiberty.a also implements malloc
> and free, how do I know which one gets called, mine or libiberty.a's?

You don't. In practice what'll happen is the linker will pull in the first
one it comes across. To see what I mean create a malloc stub (call it m.c)
that just prints something then invokes exit() & place it (m.o) into a
library (libFOO.a). For eg...

<c.c>
#include <stdlib.h>
int
main()
{
 malloc(1);
 return 0;
}
</c.c>

...you'll note different combinations of...

$gcc -o c c.c [m.o | -L. -lFOO]

...both invoke your stub whereas...

$gcc -o c c.c

...pulls in the normal malloc. Obviously hand linking direct with 'ld'
allows greater scope as one can alter the relative order of both your stub
and the "lib c" containing the real malloc.

> Actually, I would have guessed that the linker would have complained
> about this...

System problem. Silence is to be expected though. You'll have to resort to
your linker manual taking into account that shared library behaviour is not
at all the same. Back to the static libs we have here...

In essence, what you end up with is (assuming your link ends up pulling your
stub) is that some code makes use of your stub where other code may not.
The precise details depend upon the code within the official "lib c". In
your case you'll have to go through libiberty.a source and remove its
malloc etc (call it the arena). Be especially careful to discover
situations where libiberty might invoke arena code at a lower level
interface than the malloc it presents to the outside world. I'm not saying
it does (I've never looked) but the possibility must be researched. At this
point it's worth mentioning that you will no doubt encounter the point
where libiberty initialises its arena from the system itself (call that
Malloc) whereupon it may be more productive to leave libiberty malloc in
place and instead replace the Malloc.

> Anyway, I now get an undefined reference to fwrite (which I guess I
> could solve by implmeneting my own dummy fwrite) and an undefined
> reference to _impure_ptr (which I have no idea what it is). Does
> anyone have an idea on how to solve the latter undefined reference?

I thought I knew this one but alas my troublesome memory - a quick google
doesn't reveal _impure_ptr details so I'm afraid I'll leave that for you to
research. As for fwrite that's not good - one would expect it to be sat
upon write() - ie: for write() to be undefined but without reviewing
libiberty source this must be taken only as a guess on my part.