Re: [DynInst_API:] Telling DynInst a particular function is non-returning

[Thomas Dullien <thomasdullien@xxxxxxxxxx>]

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 <thomasdullien@xxxxxxxxxx> wrote:

Ah. No. I just fund set_retstatus :-) -- please ignore my question :-)

On Thu, Mar 15, 2018 at 9:26 AM, Thomas Dullien <thomasdullien@xxxxxxxxxx> 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 <thomasdullien@xxxxxxxxxx> 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