tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] tcc problems on FBSD 4.8 and patch


From: Peter \"Firefly\" Lund
Subject: Re: [Tinycc-devel] tcc problems on FBSD 4.8 and patch
Date: Tue, 22 Apr 2003 21:18:42 +0200 (MEST)

On Tue, 22 Apr 2003, Billy wrote:

> I had some problems compiling on FreeBSD.
>
>   *  -ldl doesn't exist on FreeBSD (or at least not on base system)
>   *  bcheck.c::__bound_malloc prototyped with (size_t,const void*) arglist
>      bcheck.c:L785 called __bound_calloc(size)
>
> I wrote a patch that seems to work: http://www.idiom.com/~billy/tcc.patch

Thanks for using the right MIME type (TEXT/PLAIN) -- but putting the patch
inline would have been even better.  The patch programs accepts whole
emails just fine.

An inline patch is much easier to review and comment on -- and that must
be the whole point of using patches in text format, right?

--- Makefile    Mon Apr 14 15:21:17 2003
+++ Makefile    Sun Apr 20 23:28:17 2003
@@ -3,9 +3,11 @@
 #
 include config.mak

 CFLAGS=-O2 -g -Wall
+ifeq ($(OS),"Linux")

Nice how it gets set by the config file.
(Wouldn't OS=`uname` do just as well?)

 LIBS=-ldl
+endif
 CFLAGS_P=$(CFLAGS) -pg -static -DCONFIG_TCC_STATIC
 LIBS_P=

 CFLAGS+=-mpreferred-stack-boundary=2
@@ -163,9 +165,9 @@
 libtcc.a: libtcc.o
        $(AR) rcs $@ $^

 libtcc_test: libtcc_test.c libtcc.a
-       $(CC) $(CFLAGS) -I. -o $@ $< -L. -ltcc -ldl
+       $(CC) $(CFLAGS) -I. -o $@ $< -L. -ltcc $(LIBS)


Seems reasonable so far.


 libtest: libtcc_test
        ./libtcc_test

--- bcheck.c    Mon Apr 14 15:21:17 2003
+++ bcheck.c    Sun Apr 20 23:28:17 2003
@@ -777,13 +777,13 @@
     }
 }

 #ifndef CONFIG_TCC_MALLOC_HOOKS
-void *__bound_calloc(size_t nmemb, size_t size)
+void *__bound_calloc(size_t nmemb, size_t size, const void *caller)

Perhaps __const would be better?  The bounds checking code is very tightly
bound to the memory allocator used in glibc (ptmalloc, derived from Doug
Lea's malloc) and it uses __const -- defined in malloc.h.

The same goes for the other __xxxx_hook() functions.


 {
     void *ptr;
     size = size * nmemb;
-    ptr = __bound_malloc(size);
+    ptr = __bound_malloc(size,caller);
     if (!ptr)
         return NULL;
     memset(ptr, 0, size);
     return ptr;
--- configure   Mon Apr 14 15:21:17 2003
+++ configure   Sun Apr 20 23:28:17 2003
@@ -29,8 +29,9 @@
 host_cc="gcc"
 ar="ar"
 make="make"
 strip="strip"
+os=`uname`
 cpu=`uname -m`
 case "$cpu" in
   i386|i486|i586|i686|i86pc|BePC)
     cpu="x86"
@@ -210,8 +211,9 @@
 echo "Manual  directory   $mandir"
 echo "Source path      $source_path"
 echo "C compiler       $cc"
 echo "make             $make"
+echo "OS               $os"
 echo "CPU              $cpu"
 echo "Big Endian       $bigendian"
 echo "gprof enabled    $gprof"

@@ -234,8 +236,9 @@
 echo "AR=$ar" >> config.mak
 echo "STRIP=$strip -s -R .comment -R .note" >> config.mak
 echo "CFLAGS=$CFLAGS" >> config.mak
 echo "LDFLAGS=$LDFLAGS" >> config.mak
+echo "OS=$os" >> config.mak
 if test "$cpu" = "x86" ; then
   echo "ARCH=i386" >> config.mak
   echo "#define HOST_I386 1" >> $TMPH
 elif test "$cpu" = "armv4l" ; then


> I was somewhat confused by the __bound_malloc because caller isn't
> referenced in the function definition.  Then again I probably missed
> something.

Nope, it should just be passed on, the way you did.  The ordinary
malloc()/free()/realloc()/calloc() entry points jump through a function
pointer (__malloc_hook, __free_hook, etc) which normally point to code
inside glibc but which the code in bcheck.c sets to point to its own
wrappers (save_malloc_hooks()/restore_malloc_hooks()).


> If I have some time, I would like to try and track down
> the linking issue on FreeBSD.  Any pointers or thoughts on it would be
> appreciated.

I did some googling on the subject a couple of months back to help
somebody in comp.lang.ml get mosml to compile (which is a lot simpler
than making tcc become a good FreeBSD citizen).  I think the issue was
that FreeBSD simply doesn't have a complete libdl implementation but that
they are finally looking into and (probably) deciding that this
new-fangled technology is not such a bad idea after all.

There is /some/ implementation of dlsym() and friends but it is not as
complete as in Linux (and some of the flags are missing).

-Peter

We bomb for peace on Mondays, Wednesdays and Fridays.  We bring democracy by 
bypassing
the UN voting process on Tuesdays, Thursdays and Saturdays...- Rogerborg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]