Hello friends, First I must say that I never used tcc bound checking because, as Michael said, I mostly use valgrind and other gcc/clang analysers when code security matters in devel cycle. The only possible interesting use I see is when tcc is used natively on Windows when no other C compiler is installed.
I will not complain if this feature is removed. C. -----Original Message----- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Herman ten Brugge via Tinycc-devel Sent: Thursday, November 28, 2019 18:16 To: Michael Matz Cc: Herman ten Brugge; Herman ten Brugge via Tinycc-devel Subject: Re: [Tinycc-devel] bounds checking with tcc On 2019-11-28 17:41, Michael Matz wrote: > Hello again, > > but to maybe be a bit more constructive: > > On Thu, 28 Nov 2019, Michael Matz wrote: > >>> I fixed this with some push/pop trickery. > I see, yeah, expanding calls during calls is broken as gfunc_call in the > generators doesn't generally leave a trace in vtop[] which registers are > currently holding values. I think you only need so push/pop si/di, as > cx/dx aren't used intentionally during reg-param setup. > > (I think i386-gen.c has a simila bug with fastcall functions). I did this on purpose. The register calling usage is rdi, rsi, rdx, rcx. So If a call uses four parameters the rdx, rcx would be overwritten by the bounds checking code. The bound_ptr_indirx calls overwrite rdi, rsi, rdx and rcx. > >>> This probably could be >>> improved. I have now added a minimum patch so bounds checking works a >>> little bit. We need still to fix the shared lib reloc problems and the >>> malloc/free hooks. >> Do we? Can we perhaps also simply declare bounds checking to work only >> with the main executable? Or remove that whole feature altogether? > And perhaps another compromise: only conditionally enable tracking of > locals: Invent a new cmdline option (say, '-bb'), which sets > do_bounds_checking to 2. And only if it's > 1 you would also track > locals, whereas with == 1 you would only track arrays and structs. > > Your decision, I think you can push this patch either with that change, or > without (but try to remove cx/dx from the push/pop). It doesn't make tccs > source code larger or uglier in any meaningful way, but does fix practical > bugs. I can make a patch for this and as well. Currently I think the best thing to do is to remove it. Other tools do a much better job. If you still want to keep the code we probably should add some warnings. For example do not use it for shared libraries. Regards, Herman _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
