Xiaozhu,
Would this handling of non-return functions be fixed by the patch that you sent
to me for PPC?
--
John Mellor-Crummey
(sent from my phone)
> On Mar 15, 2018, at 8:02 AM, Thomas Dullien <thomasdull...@google.com> wrote:
>
> Hey there,
>
> ok, rebuilding DynInst 9.3.2 now to investigate why adding the string does
> not seem to have any effect.
> I looked at the source code, and I *think* the function is already in the
> list of non-returning functions.
>
> Checking what is going on. Example setup:
>
> .plt.got:0000000000053CF8 __stack_chk_fail proc near ; CODE
> XREF: init:loc_54673↓p
> .plt.got:0000000000053CF8 ;
> uninit:loc_54705↓p ...
> .plt.got:0000000000053CF8 jmp cs:__stack_chk_fail_ptr
> .plt.got:0000000000053CF8 __stack_chk_fail endp
>
> .text:00000000000A4290 var_8 = qword ptr -8
> .text:00000000000A4290
> .text:00000000000A4290 graph = rdi ;
> AVFilterGraph_0 *
> .text:00000000000A4290 flags = rsi ; unsigned int
> .text:00000000000A4290 ; __unwind {
> .text:00000000000A4290 push rax
> .text:00000000000A4291 mov rax, fs:28h
> .text:00000000000A429A mov [rsp+8+var_8], rax
> .text:00000000000A429E mov [graph+5Ch], esi
> .text:00000000000A42A1 mov rax, fs:28h
> .text:00000000000A42AA cmp rax, [rsp+8+var_8]
> .text:00000000000A42AE jnz short loc_A42B2
> .text:00000000000A42B0 pop rax
> .text:00000000000A42B1 retn
> .text:00000000000A42B2 ;
> ---------------------------------------------------------------------------
> .text:00000000000A42B2
> .text:00000000000A42B2 loc_A42B2: ; CODE XREF:
> avfilter_graph_set_auto_convert+1E↑j
> .text:00000000000A42B2 call __stack_chk_fail
> .text:00000000000A42B2 ; } // starts at A4290
> .text:00000000000A42B2 avfilter_graph_set_auto_convert endp
>
> DynInst for some reason does not interpret the tailing call as non-return.
> Digging to see what is going on,
> will update here as I learn more :)
>
> Cheers,
> Thomas
>
>
>> On Thu, Mar 15, 2018 at 1:58 PM, Xiaozhu Meng <mxz...@gmail.com> wrote:
>> Hi Thomas,
>>
>>> On Thu, Mar 15, 2018 at 4:06 AM, Thomas Dullien <thomasdull...@google.com>
>>> wrote:
>>> Hey there,
>>>
>>> ok, I have looked at a few options on how to best tackle this, and would
>>> love to solicit advice :-)
>>>
>>> - I tried SymtabCodeSource::addNonReturning("__stack_chk_fail"); this did
>>> not seem to have an effect.
>>
>> If you call SymtabCodeSource::addNonReturning("__stack_chk_fail") before
>> calling CodeObject::parse(), this should work.
>>
>>> - Looked at set_retstatus -- but that implies that the code is already
>>> parsed?
>>
>> You are right that after CodeObject::parse() has finished, calling
>> set_retstatus will only change the flag of return status for this function,
>> will not re-parse the binary. So, we can focus on why
>> SymtabCodeSource::addNonReturning("__stack_chk_fail") does not work.
>>
>>
>>
>>>
>>> Cheers,
>>> Thomas
>>>
>>>
>>>> On Thu, Mar 15, 2018 at 9:28 AM, Thomas Dullien <thomasdull...@google.com>
>>>> wrote:
>>>> Ah. No. I just fund set_retstatus :-) -- please ignore my question :-)
>>>>
>>>>> On Thu, Mar 15, 2018 at 9:26 AM, Thomas Dullien
>>>>> <thomasdull...@google.com> wrote:
>>>>> Hey there,
>>>>>
>>>>> after having my coffee, I realized: The proper way to do this is to
>>>>> derive from CodeSource
>>>>> and overload the nonReturning functions, I guess? :)
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>>
>>>>>> On Thu, Mar 15, 2018 at 9:14 AM, Thomas Dullien
>>>>>> <thomasdull...@google.com> wrote:
>>>>>> Hey there,
>>>>>>
>>>>>> I am running into troubles with disassembling executables generated by
>>>>>> clang.3.8.1-24, for x64, with optimization set to size-optimize and
>>>>>> stack cookies
>>>>>> enabled.
>>>>>>
>>>>>> The trouble is that any function with an enabled stack cookie will end
>>>>>> with a sequence
>>>>>> of:
>>>>>>
>>>>>> Epilogue to check stack cookie
>>>>>> jnz .fail
>>>>>> Rest of epilogue.
>>>>>> retn
>>>>>> .fail:
>>>>>> call __stack_checkfail // Does not return
>>>>>>
>>>>>> This leads to DynInst lumping all consecutive functions that use stack
>>>>>> cookies
>>>>>> into one huge CFG.
>>>>>>
>>>>>> Is there a way to tell DynInst that a particular function is not
>>>>>> returning? I found
>>>>>> that the parseAPI allows me to query if a function returns, but I did
>>>>>> not find anything
>>>>>> to "override" this behavior?
>>>>>>
>>>>>> Cheers,
>>>>>> Thomas
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Dyninst-api mailing list
>>> Dyninst-api@cs.wisc.edu
>>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>>
>
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@cs.wisc.edu
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
