Re: [Tinycc-devel] tcc_relocate() and tcc_relocate_ex()

[Sean Conner]

It was thus said that the Great grischka once stated:
> Sean Conner wrote:
> >>As to the patch I think that
> >>    +    s1->runtime_mem = NULL;
> >>would break tcc_relocate and I don't see why you need it.
> >
> >  I did that so that the call to tcc_delete() wouldn't crash when it tried
> >to free s->runtime_mem that might contain a garbage value (since
> >tcc_relocate_ex() would never set that field).  Good thing too, because
> >tcc_new() *might not* be initializing NULL pointers correctly [1].
> 
> Well, from my point of view that line would not fix tcc_new
> but cause a memory leak for tcc_relocate.

  Here's the output from valgrind running tcc using the current source code:

[spc]lucy:~/apps/tinycc>valgrind ./tcc -c libtcc.c -DTCC_TARGET_I386 
-DONE_SOURCE  
==10945== Memcheck, a memory error detector.
==10945== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==10945== Using LibVEX rev 1575, a library for dynamic binary translation.
==10945== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==10945== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==10945== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==10945== For more details, rerun with: -v
==10945== 
==10945== 
==10945== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==10945== malloc/free: in use at exit: 0 bytes in 0 blocks.
==10945== malloc/free: 93,402 allocs, 93,402 frees, 41,400,839 bytes allocated.
==10945== For counts of detected errors, rerun with: -v
==10945== All heap blocks were freed -- no leaks are possible.

  And the output with the patch:

[spc]lucy:~/apps/tinycc>valgrind ./tcc -c libtcc.c -DTCC_TARGET_I386 
-DONE_SOURCE
==11070== Memcheck, a memory error detector.
==11070== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==11070== Using LibVEX rev 1575, a library for dynamic binary translation.
==11070== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==11070== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==11070== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==11070== For more details, rerun with: -v
==11070== 
==11070== 
==11070== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==11070== malloc/free: in use at exit: 0 bytes in 0 blocks.
==11070== malloc/free: 49,772 allocs, 49,772 frees, 19,867,951 bytes allocated.
==11070== For counts of detected errors, rerun with: -v
==11070== All heap blocks were freed -- no leaks are possible.

  And further more, here's a program I wrote that uses tcc_relocate_ex():

[spc]lucy:~/source/synthesis>valgrind ./m >/dev/null
==11077== Memcheck, a memory error detector.
==11077== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==11077== Using LibVEX rev 1575, a library for dynamic binary translation.
==11077== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==11077== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==11077== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==11077== For more details, rerun with: -v
==11077== 
f1 1.128470000
f2 0.369861000

==11077== 
==11077== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 22 from 2)
==11077== malloc/free: in use at exit: 1,109 bytes in 7 blocks.
==11077== malloc/free: 7,441 allocs, 7,434 frees, 1,867,222 bytes allocated.
==11077== For counts of detected errors, rerun with: -v
==11077== searching for pointers to 7 not-freed blocks.
==11077== checked 179,256 bytes.
==11077== 
==11077== LEAK SUMMARY:
==11077==    definitely lost: 0 bytes in 0 blocks.
==11077==      possibly lost: 0 bytes in 0 blocks.
==11077==    still reachable: 1,109 bytes in 7 blocks.
==11077==         suppressed: 0 bytes in 0 blocks.
==11077== Reachable blocks (those to which a pointer was found) are not shown.
==11077== To see them, rerun with: --show-reachable=yes

(The program loads and compiles the same file twice (with some differences
in what's defined) using different TCC states for each file and runs
both---what you are seeing is how long it took to compile the file each
time---valgrind is affecting the speed of the first compile).

> >  -spc (But I would feel safer with the NULL pointer assignment ... )
> 
> (That's what I suspected ...)

  -spc (Well, I do work in the QA department at my company ... )