[Top][All Lists]

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

Re: [Tinycc-devel] Bounds mixing non malloced strings is the reason to m

From: Thomas Preudhomme
Subject: Re: [Tinycc-devel] Bounds mixing non malloced strings is the reason to make tests fail on linux 32bits
Date: Sun, 30 Mar 2014 11:50:35 +0800
User-agent: Roundcube Webmail/0.7.2

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.



reply via email to

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