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.
- Looked at set_retstatus -- but that implies that the code is already
parsed?

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

Reply via email to