Re: [Tinycc-devel] Bounds mixing non malloced strings is the reason to make tests fail on linux 32bits

[Thomas Preudhomme]

Le 2014-03-30 01:01, Domingo Alvarez Duarte a écrit :
> Hello all !
>
> I followed the code and could see that mixing strings malloced and 
> not
> malloced by tcc is the reason for the test to fail on linux 32 bits.

Have you tried compiling with -b switch? There is still some bugs in 
bound checking code.

> On that particular case we are mixing a string from program argv[]
> with the tcc bounds checking, the later expect all strings to have
> been malloced by __bound_malloc that adds an extra byte to the size,
> but the strings from program parameters argv[] seem to be allocated
> without __bound_malloc and then the false BAD_POINTER is raised.
>
> Who did this ?

Mmmh, that's me. There was bound checking when doing *argv and that 
made the bound checking work in this case. But indeed, I didn't think 
about when accessed as array. I fail to see how it could work before. 
For objects defined in a different compilation unit, there is no way to 
know if it will be compiled by tcc or not. So either you don't do any 
bound checking for object not defined within the compilation unit you 
are compiling, or you do it on all objects but it will fail for those 
not compiled by tcc.

I was trying to make at least argv and arge work as they are probably 
the most frequently encountered object comming from outside a program (I 
assume usually people compile a whole program with tcc). To make it a 
more general solution we could teach the bound checking code about all 
the memory region used by libraries and tcc. If a pointer is in program 
area, normal bound checking occurs, else if it's in a library area it 
just returns without error and if outside it returns -2 like now. I'll 
think about how to discover the mapping at runtime and see if I can 
implement this for 0.9.27.


> If we do the tests without compiled tcc by tcc it works fine, I
> propose to move those tests to the compiled tcc instead of tcc 
> running
> by other tcc.

Certainly not. a test is meant to fail when there is a problem. When 
that is the case you fix the bug or declare the situation as not 
supported. I prefer the former.

> It sounds a bit crazy but if someone can come in to help clarify this
> we can together solve this problem.

See above.

Cheers,

Thomas