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 <[email protected]> wrote:
> Hi Thomas,
>
> On Thu, Mar 15, 2018 at 4:06 AM, Thomas Dullien <[email protected]>
> 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 <[email protected]
>> > wrote:
>>
>>> Ah. No. I just fund set_retstatus :-) -- please ignore my question :-)
>>>
>>> On Thu, Mar 15, 2018 at 9:26 AM, Thomas Dullien <
>>> [email protected]> 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 <
>>>> [email protected]> 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
>> [email protected]
>> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>>
>
>
_______________________________________________
Dyninst-api mailing list
[email protected]
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
