[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