standalone backtraces

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

standalone backtraces

grischka
Hi folks,

Thought the entire bcheck stuff is pretty much completely useless
if it doesn't give you any hint where in the your code the problem
actually happens.  So I added some patch of mine that allows tcc to
include the backtrace features for -run into standalone executables.

It should work with DLLs/SOs too (i.e. multiple instances of stab
debug infos).  See

        https://repo.or.cz/tinycc.git/commitdiff/ef42295f

--- grischka

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: standalone backtraces

Christian Jullien-3
Hi Grischka,

Thank you for this very useful contribution. I have however a concern on the way you load the different new files:
+#ifdef CONFIG_TCC_BACKTRACE
+    if (s1->do_backtrace) {
+#ifdef CONFIG_TCC_BCHECK
+        if (s1->do_bounds_check && s1->output_type != TCC_OUTPUT_DLL)
+            tcc_add_support(s1, "bcheck.o");
+#endif
+        if (s1->output_type == TCC_OUTPUT_EXE)
+            tcc_add_support(s1, "bt-exe.o");
+        if (s1->output_type == TCC_OUTPUT_DLL)
+            tcc_add_support(s1, "bt-dll.o");
+        if (s1->output_type != TCC_OUTPUT_DLL)
+            tcc_add_support(s1, "bt-log.o");
+        if (s1->output_type != TCC_OUTPUT_MEMORY)
+            tcc_add_btstub(s1);
+    }
+#endif

It supposes that there is only one memory model (either 32 or 64). More specifically, it prevents tcc to support multi-archive using -m32/-m64.
IMHO, it would be better to build libbcheck.a (or whatever name you like) which contains all material to support bound checking and bt.
Multi-archive will internally use libbcheck-32.a and libbcheck-64.a

Wdyt?

C.

-----Original Message-----
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of grischka
Sent: Friday, January 17, 2020 23:22
To: [hidden email]
Subject: [Tinycc-devel] standalone backtraces

Hi folks,

Thought the entire bcheck stuff is pretty much completely useless
if it doesn't give you any hint where in the your code the problem
actually happens.  So I added some patch of mine that allows tcc to
include the backtrace features for -run into standalone executables.

It should work with DLLs/SOs too (i.e. multiple instances of stab
debug infos).  See

        https://repo.or.cz/tinycc.git/commitdiff/ef42295f

--- grischka

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: standalone backtraces

tinycc-devel mailing list
I just committed https://svn.code.sf.net/p/wintcc/svn wine/Makefile.

This now supports 32 and 64 bits in same directory.

Probably the same can be done for the cygwin/Makefile.

Regards,

     Herman

On 2020-01-18 08:32, Christian Jullien wrote:

> Hi Grischka,
>
> Thank you for this very useful contribution. I have however a concern on the way you load the different new files:
> +#ifdef CONFIG_TCC_BACKTRACE
> +    if (s1->do_backtrace) {
> +#ifdef CONFIG_TCC_BCHECK
> +        if (s1->do_bounds_check && s1->output_type != TCC_OUTPUT_DLL)
> +            tcc_add_support(s1, "bcheck.o");
> +#endif
> +        if (s1->output_type == TCC_OUTPUT_EXE)
> +            tcc_add_support(s1, "bt-exe.o");
> +        if (s1->output_type == TCC_OUTPUT_DLL)
> +            tcc_add_support(s1, "bt-dll.o");
> +        if (s1->output_type != TCC_OUTPUT_DLL)
> +            tcc_add_support(s1, "bt-log.o");
> +        if (s1->output_type != TCC_OUTPUT_MEMORY)
> +            tcc_add_btstub(s1);
> +    }
> +#endif
>
> It supposes that there is only one memory model (either 32 or 64). More specifically, it prevents tcc to support multi-archive using -m32/-m64.
> IMHO, it would be better to build libbcheck.a (or whatever name you like) which contains all material to support bound checking and bt.
> Multi-archive will internally use libbcheck-32.a and libbcheck-64.a
>
> Wdyt?
>
> C.
>
> -----Original Message-----
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of grischka
> Sent: Friday, January 17, 2020 23:22
> To: [hidden email]
> Subject: [Tinycc-devel] standalone backtraces
>
> Hi folks,
>
> Thought the entire bcheck stuff is pretty much completely useless
> if it doesn't give you any hint where in the your code the problem
> actually happens.  So I added some patch of mine that allows tcc to
> include the backtrace features for -run into standalone executables.
>
> It should work with DLLs/SOs too (i.e. multiple instances of stab
> debug infos).  See
>
> https://repo.or.cz/tinycc.git/commitdiff/ef42295f
>
> --- grischka
>
> _______________________________________________
> Tinycc-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: standalone backtraces

tinycc-devel mailing list
In reply to this post by grischka
Thanks for doing this. This was indeed needed.

There are 2 problems I see.

The first one is that you removed the alloca/vla code for bounds checking.
The following program:

extern void *alloca(int size);
void tst1(void) { void *a = alloca(16); }
void tst2(void) { int i; int a[10]; for (i=0;i<10;i++)a[i]=0; }

int main(void) { tst1(); tst2(); }

When compiled with bounds checking it fails. The alloca
is not deleted because no __bound_local_delete is generated.
The original code in tccgen.c created a dummy lbounds section
so that __bound_local_new(not needed) and __bound_local_delete
were generated.
For the same reason the tests/tests2/79_vla_continue.c fails when
compiled with bounds checking.



The other problem is that testcase 112 produces on linux:
# ./tcc -b -dt 112_backtrace.c -o 112_backtrace -Dtest_bcheck_100
# ./112_backtrace
112_backtrace.c:107: at main: BCHECK: 0x7ffed562f6e4 is outside of the
region
112_backtrace.c:107: at main: BCHECK: invalid pointer 0x7ffed562f6da,
size 0xa in memcpy dest

This looks correct.

But on windows (and wine) I get:
# ./tcc.exe -b -dt 112_backtrace.c -o 112_backtrace.exe -Dtest_bcheck_100
# ./112_backtrace.exe
00401535 : at ???: BCHECK: 000000000022FA84 is outside of the region
00404447 : by ???
00404666 : by ???
112_backtrace.c:107: by main
0040447a : at ???: BCHECK: invalid pointer 000000000022FA7A, size 0xa in
memcpy dest
00404666 : by ???
112_backtrace.c:107: by main

All other tests in 112_backtrace.c have simular problems.

Perhaps I did something wrong with windows/wine. I only use windows
to update my tomtom.

The makefile for wine I used is at: https://svn.code.sf.net/p/wintcc/svn

Regards,

         Herman

On 2020-01-17 23:21, grischka wrote:

> Hi folks,
>
> Thought the entire bcheck stuff is pretty much completely useless
> if it doesn't give you any hint where in the your code the problem
> actually happens.  So I added some patch of mine that allows tcc to
> include the backtrace features for -run into standalone executables.
>
> It should work with DLLs/SOs too (i.e. multiple instances of stab
> debug infos).  See
>
>     https://repo.or.cz/tinycc.git/commitdiff/ef42295f
>
> --- grischka
>


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: standalone backtraces

grischka
Herman ten Brugge via Tinycc-devel wrote:

> Thanks for doing this. This was indeed needed.
>
> There are 2 problems I see.
>
> The first one is that you removed the alloca/vla code for bounds checking.
> The following program:
>
> extern void *alloca(int size);
> void tst1(void) { void *a = alloca(16); }
> void tst2(void) { int i; int a[10]; for (i=0;i<10;i++)a[i]=0; }
>
> int main(void) { tst1(); tst2(); }
>
> When compiled with bounds checking it fails. The alloca
> is not deleted because no __bound_local_delete is generated.
> The original code in tccgen.c created a dummy lbounds section
> so that __bound_local_new(not needed) and __bound_local_delete
> were generated.

How many dummy entries do you need to make sure __bound_local_delete
is called, and do you need any at all, really?

> For the same reason the tests/tests2/79_vla_continue.c fails when
> compiled with bounds checking.

>
> The other problem is that testcase 112 produces on linux:
> # ./tcc -b -dt 112_backtrace.c -o 112_backtrace -Dtest_bcheck_100
> # ./112_backtrace
> 112_backtrace.c:107: at main: BCHECK: 0x7ffed562f6e4 is outside of the
> region
> 112_backtrace.c:107: at main: BCHECK: invalid pointer 0x7ffed562f6da,
> size 0xa in memcpy dest
>
> This looks correct.
>
> But on windows (and wine) I get:
> # ./tcc.exe -b -dt 112_backtrace.c -o 112_backtrace.exe -Dtest_bcheck_100
> # ./112_backtrace.exe
> 00401535 : at ???: BCHECK: 000000000022FA84 is outside of the region
> 00404447 : by ???
> 00404666 : by ???
> 112_backtrace.c:107: by main
> 0040447a : at ???: BCHECK: invalid pointer 000000000022FA7A, size 0xa in
> memcpy dest
> 00404666 : by ???
> 112_backtrace.c:107: by main

That looks like missing -g when bcheck.c was compiled.

Btw, there seems to be a bug in the sym-version code that crashes
tcc when it tries to link with a .so, for example:

     echo "void f() {}" | tcc - -shared -o a.so
     echo "main() {}" | tcc - a.so
     <segmentation fault>

Thanks,

--- grischka

> All other tests in 112_backtrace.c have simular problems.
>
> Perhaps I did something wrong with windows/wine. I only use windows
> to update my tomtom.
>
> The makefile for wine I used is at: https://svn.code.sf.net/p/wintcc/svn
>
> Regards,
>
>         Herman
>
> On 2020-01-17 23:21, grischka wrote:
>> Hi folks,
>>
>> Thought the entire bcheck stuff is pretty much completely useless
>> if it doesn't give you any hint where in the your code the problem
>> actually happens.  So I added some patch of mine that allows tcc to
>> include the backtrace features for -run into standalone executables.
>>
>> It should work with DLLs/SOs too (i.e. multiple instances of stab
>> debug infos).  See
>>
>>     https://repo.or.cz/tinycc.git/commitdiff/ef42295f
>>
>> --- grischka

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: standalone backtraces

tinycc-devel mailing list
On 2020-01-19 02:01, grischka wrote:

> Herman ten Brugge via Tinycc-devel wrote:
>> Thanks for doing this. This was indeed needed.
>>
>> There are 2 problems I see.
>>
>> The first one is that you removed the alloca/vla code for bounds
>> checking.
>> The following program:
>>
>> extern void *alloca(int size);
>> void tst1(void) { void *a = alloca(16); }
>> void tst2(void) { int i; int a[10]; for (i=0;i<10;i++)a[i]=0; }
>>
>> int main(void) { tst1(); tst2(); }
>>
>> When compiled with bounds checking it fails. The alloca
>> is not deleted because no __bound_local_delete is generated.
>> The original code in tccgen.c created a dummy lbounds section
>> so that __bound_local_new(not needed) and __bound_local_delete
>> were generated.
>
> How many dummy entries do you need to make sure __bound_local_delete
> is called, and do you need any at all, really?
I need only 1. I modified the code. See attached patch.
This solves both problems.
There is no alloca_free() so I need a trigger to remove the alloca/vla data.

>>
>> The other problem is that testcase 112 produces on linux:
>> # ./tcc -b -dt 112_backtrace.c -o 112_backtrace -Dtest_bcheck_100
>> # ./112_backtrace
>> 112_backtrace.c:107: at main: BCHECK: 0x7ffed562f6e4 is outside of the
>> region
>> 112_backtrace.c:107: at main: BCHECK: invalid pointer 0x7ffed562f6da,
>> size 0xa in memcpy dest
>>
>> This looks correct.
>>
>> But on windows (and wine) I get:
>> # ./tcc.exe -b -dt 112_backtrace.c -o 112_backtrace.exe
>> -Dtest_bcheck_100
>> # ./112_backtrace.exe
>> 00401535 : at ???: BCHECK: 000000000022FA84 is outside of the region
>> 00404447 : by ???
>> 00404666 : by ???
>> 112_backtrace.c:107: by main
>> 0040447a : at ???: BCHECK: invalid pointer 000000000022FA7A, size 0xa in
>> memcpy dest
>> 00404666 : by ???
>> 112_backtrace.c:107: by main
>
> That looks like missing -g when bcheck.c was compiled.
Oops. Need more coffee.
Fixed the Makefile.
>
> Btw, there seems to be a bug in the sym-version code that crashes
> tcc when it tries to link with a .so, for example:
>
>     echo "void f() {}" | tcc - -shared -o a.so
>     echo "main() {}" | tcc - a.so
>     <segmentation fault>
I cannot reproduce this. I checkout a fresh copy and see no problem.
I use Fedora 31 with all updates.

Regards,

     Herman


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: standalone backtraces

grischka
Herman ten Brugge wrote:
> I need only 1. I modified the code. See attached patch.

I don't think so.

Basically, in tinycc, before you add new code, always try if you
can solve the problem by just removing old code first.

(Also, please don't make changes to existing code without any
comments, unless really obvious for everybody).

Anyway, should work now. See
https://repo.or.cz/tinycc.git/commitdiff/d79e1dee

>> Btw, there seems to be a bug in the sym-version code that crashes
>> tcc when it tries to link with a .so, for example:
>>
>>     echo "void f() {}" | tcc - -shared -o a.so
>>     echo "main() {}" | tcc - a.so
>>     <segmentation fault>

> I cannot reproduce this. I checkout a fresh copy and see no problem.
> I use Fedora 31 with all updates.

see for example
   https://gitlab.com/giomasce/tinycc/-/jobs/408014593

  +./a.exe: error while loading shared libraries: ./a1.so: unsupported version
    25960 of Verneed record

--- grischka

>
> Regards,
>
>     Herman
>

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: standalone backtraces

Christian Jullien-3
> Basically, in tinycc, before you add new code, always try if you can solve the problem by just removing old code first.

Yup, Antoine de Saint-Exupéry said: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.".
In the same vein, Leonardo da Vinci who wrote: “Simplicity is the ultimate sophistication”.

It's so hard to make things simple.


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: standalone backtraces

tinycc-devel mailing list
In reply to this post by grischka
Your code change made the bounds-checking code 30% slower.
The __bound_local_new/__bound_local_delete is now called for every function.
There was an optimization to call it only when lbounds_section was used
in a function.

Regards,

     Herman


On 2020-01-19 12:06, grischka wrote:

> Herman ten Brugge wrote:
>> I need only 1. I modified the code. See attached patch.
>
> I don't think so.
>
> Basically, in tinycc, before you add new code, always try if you
> can solve the problem by just removing old code first.
>
> (Also, please don't make changes to existing code without any
> comments, unless really obvious for everybody).
>
> Anyway, should work now. See
> https://repo.or.cz/tinycc.git/commitdiff/d79e1dee
>
>>> Btw, there seems to be a bug in the sym-version code that crashes
>>> tcc when it tries to link with a .so, for example:
>>>
>>>     echo "void f() {}" | tcc - -shared -o a.so
>>>     echo "main() {}" | tcc - a.so
>>>     <segmentation fault>
>
>> I cannot reproduce this. I checkout a fresh copy and see no problem.
>> I use Fedora 31 with all updates.
>
> see for example
>   https://gitlab.com/giomasce/tinycc/-/jobs/408014593
>
>  +./a.exe: error while loading shared libraries: ./a1.so: unsupported
> version
>    25960 of Verneed record
>
> --- grischka
>
>>
>> Regards,
>>
>>     Herman
>>


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: standalone backtraces

tinycc-devel mailing list
In reply to this post by grischka
On 2020-01-19 12:06, grischka wrote:

> Herman ten Brugge wrote:
>
>>> Btw, there seems to be a bug in the sym-version code that crashes
>>> tcc when it tries to link with a .so, for example:
>>>
>>>     echo "void f() {}" | tcc - -shared -o a.so
>>>     echo "main() {}" | tcc - a.so
>>>     <segmentation fault>
>
>> I cannot reproduce this. I checkout a fresh copy and see no problem.
>> I use Fedora 31 with all updates.
>
> see for example
>   https://gitlab.com/giomasce/tinycc/-/jobs/408014593
>
>  +./a.exe: error while loading shared libraries: ./a1.so: unsupported
> version
>    25960 of Verneed record
I could reproduce this. The attached patch fixes this.

Regards,

     Herman


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: standalone backtraces

Michael Matz-4
In reply to this post by grischka
Hi,

On Sun, 19 Jan 2020, grischka wrote:

> Herman ten Brugge wrote:
>>  I need only 1. I modified the code. See attached patch.
>
> I don't think so.
>
> Basically, in tinycc, before you add new code, always try if you
> can solve the problem by just removing old code first.
>
> (Also, please don't make changes to existing code without any
> comments, unless really obvious for everybody).
>
> Anyway, should work now. See
> https://repo.or.cz/tinycc.git/commitdiff/d79e1dee
>
>>>  Btw, there seems to be a bug in the sym-version code that crashes
>>>  tcc when it tries to link with a .so, for example:
>>>
>>>      echo "void f() {}" | tcc - -shared -o a.so
>>>      echo "main() {}" | tcc - a.so
>>>      <segmentation fault>
>
>>  I cannot reproduce this. I checkout a fresh copy and see no problem.
>>  I use Fedora 31 with all updates.
>

> see for example
>   https://gitlab.com/giomasce/tinycc/-/jobs/408014593
>
>  +./a.exe: error while loading shared libraries: ./a1.so: unsupported
>  version
>    25960 of Verneed record

Fixed in https://repo.or.cz/tinycc.git/commitdiff/fdeeb62

Also the stack usage for nested expressions you noted in the
d79e1dee commit might be be a bit smaller now, I've reworked the
expression parser to be a precedence parser for the easy cases, so there's
now only one recursion level per higher precedence operator.  Of course
it's still possible to write expression that need unbounded recursion
depth.


Ciao,
Michael.

>
> --- grischka
>
>>
>>  Regards,
>>
>>      Herman
>>
>
> _______________________________________________
> Tinycc-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel