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


Date: Thu, 15 Mar 2018 14:02:51 +0100
From: Thomas Dullien <thomasdullien@xxxxxxxxxx>
Subject: Re: [DynInst_API:] Telling DynInst a particular function is non-returning
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 <mxz297@xxxxxxxxx> wrote:
Hi Thomas,

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




_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api


[← Prev in Thread] Current Thread [Next in Thread→]