Ah, I have a few pending commits related to this issue. Please look at my pull request at https://github.com/dyninst/dyninst/pull/437.
Not all commits are relevant to you, but bbac557, 78b1bd1, da50a37 should be relevant. For parsing_printf, it is "DYNINST_DEBUG_PARSING". On Thu, Mar 15, 2018 at 8:02 AM, Thomas Dullien <[email protected]> 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 <[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 >
_______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
