[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] bounds checking with tcc
From: |
Herman ten Brugge |
Subject: |
Re: [Tinycc-devel] bounds checking with tcc |
Date: |
Thu, 28 Nov 2019 18:16:12 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 |
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