tinycc-devel
[Top][All Lists]
Advanced

[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





reply via email to

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