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
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
