tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tinycc-devel] unsubscribe


From: Yasser Taima
Subject: [Tinycc-devel] unsubscribe
Date: Sun, 30 Mar 2014 09:15:44 -0700

unsubscribe
end

> On Mar 30, 2014, at 8:56, Kirill Smelkov <address@hidden> wrote:
> 
> Hi Thomas,
> 
>> On Thu, Mar 20, 2014 at 10:20:21PM +0800, Thomas Preud'homme wrote:
>> Le dimanche 19 janvier 2014, 17:03:32 Kirill Smelkov a écrit :
>> 
>> Hi Kirill,
>> 
>>> 
>>> Sorry for being silent for so long. I've started looking into the
>>> problem today, but before I've ever got to mksh, I've found one new bug
>>> wrt bcheck which is now fixed. Could you please see, does it maybe fixes
>>> mksh? If not, I'm willing to continue digging, only it will be very
>>> slow, as my time is very tight this days...
>> 
>> I've looked into it this week and managed to fix one bug with regards to 
>> relocation of __bound_init (see commit 
>> ec1c83081dd741bd18ca1821bf52535c444dc111) but there is still at least one 
>> other bug. As I understand it the problem is that mksh loop over argv 
>> entries 
>> in main with something like "while (!*argv)". This triggers a segfault by 
>> bound_ptr_indir returning INVALID_POINTER. So I guess there is nothing right 
>> now to add argv[] and environ[] among the ok zones. I was thinking about 
>> doing 
>> it in __bound_init but there is some difficulty. From the environ variable 
>> it's 
>> easy to find the beginning and end of environ array by browsing it. 
>> Alternatively setenv of a new variable could do it in a faster way but there 
>> is the risk of the array to be already full so the browsing seems more 
>> reliable. The problem is to find the beginning and end of argv[]. For 
>> instance, 
>> I don't know if with address space randomization the environ follows 
>> immediately the end of argv (it seems to be the case on my machine). As to 
>> the 
>> beginning of argv, I can only think of taking the address of a local 
>> variable 
>> but that's only an approximation.
>> 
>> Alternatively, a different prologue could be generated for the main function 
>> that calls a __bound_new_argument_region that would take as parameter argv 
>> and 
>> then environ. What do you think about it? Do you feel like trying?
>> 
>> Best regards,
>> 
>> Thomas
> 
> Just a quick note, that I've got your message and was able to reproduce
> mksh 0.38-3 breakage with `tcc -b`, and also, as I hope, found a small
> test-case for argv v.s. bcheck crash which is below.
> 
> When I have my next free time, I'll try to analyze it, but that should
> not be soon as I'm currently very busy...
> 
> Thanks,
> Kirill
> 
> ---- 8< ----
> /* то работает - то выпадает
> address@hidden:~/src/tools/tinycc$ ./a.out
> stack:  0xffceb3f4
> argv:   0xffceb494
>        e:  .start: 0  .size: ffffffff  invalid: 0
> region dump:
> 0804b400: 0804b43b:0804b449 0804b430:0804b43a 0804b424:0804b42f
> argv[0]:        0xffced297
> address@hidden:~/src/tools/tinycc$ ./a.out
> stack:  0xfffbfee4
> argv:   0xfffbff84
>        e:  .start: 0  .size: 0  invalid: 1
> region dump:
> 0804b400: 0804b43b:0804b449 0804b430:0804b43a 0804b424:0804b42f
> E: __bound_ptr_indir4(0xfffbff84, 0x0)
> Ошибка сегментирования (core dumped)
> */
> 
> #include <stdio.h>
> 
> int main(int argc, const char *argv[])
> {
>    int i;
> 
>    printf("stack:\t%p\n", &i);
>    printf("argv:\t%p\n", argv);
>    for (i = 0; i<argc; ++i)
>        printf("argv[%i]:\t%p\n", i, argv[i]);
> 
>    return 0;
> }
> 
> _______________________________________________
> Tinycc-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel



reply via email to

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