On Wed, 2021-07-21 at 21:44 +0530, Ankur Saini wrote: > > > > On 17-Jul-2021, at 2:57 AM, David Malcolm <dmalc...@redhat.com> > > wrote: > > > > On Fri, 2021-07-16 at 21:04 +0530, Ankur Saini wrote: > > > > > > > > > > On 15-Jul-2021, at 4:53 AM, David Malcolm <dmalc...@redhat.com> > > > > wrote: > > > > > > > > On Wed, 2021-07-14 at 22:41 +0530, Ankur Saini wrote: > > > > > > > > > >
[...snip...] > > > > > > I have attached a sample patch of work done till now with this > > > mail for > > > review ( I haven’t sent this one to the patches list as it’s > > > change log > > > was not complete for now ). > > > > > > P.S. I have also sent another mail ( > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575396.html < > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575396.html> > > > ) to > > > patches list with the previous call-string patch and this time it > > > popped up in my inbox as it should, did you also received it now > > > ? > > > > I can see it in the archive URL, but for some reason it's not > > showing > > up in my inbox. Bother. Please can you try resending it directly > > to > > me? > > Ok, I have sent the call-string patch directly to you. I have > actually sent 2 mails ( from different mail ids ) to check if it’s > the id which is causing the issue or the contents of the mail itself. I've been looking, but I don't see the patch. Sorry about this. > > > > > Putting email issues to one side, the patch you linked to above > > looks > > good. To what extent has it been tested? If it bootstraps and > > passes > > the test suite, it's ready for trunk. > > It bootstrapped successfully on a couple of the x86_64 machines ( on > gcc farm ) And regress testing is underway. Great. [...snip....] > > > > In any case, the output above is missing some events: I think > > ideally > > it would show the calls from *fun_ptr to fun and the returns, > > giving > > something like the following (which I mocked up by hand): > > > > 'double_call': events 1-3 > > | > > | 16 | void double_call() > > | | ^~~~~~~~~~~ > > | | | > > | | (1) entry to 'double_call' > > | 17 | { > > | 18 | int *int_ptr = (int*)malloc(sizeof(int)); > > | | ~~~~~~~~~~~~~~~~~~~ > > | | | > > | | (2) allocated here > > | ... | > > | 19 | (*fun_ptr)(int_ptr); > > | | ^~~~~~~~~~~~~~~~~~~ > > | | | > > | | (3) calling 'fun' from 'double-call' > > | > > +--> 'fun': events 3-6 > > | > > | 4 | void fun(int *int_ptr) > > | | ^~~ > > | | | > > | | (4) entry to ‘fun’ > > | 5 | { > > | 6 | free(int_ptr); > > | | ~~~~~~~~~~~~~ > > | | | > > | | (5) first 'free' here > > | > > <------+ > > | > > 'double_call': events 6-7 > > | > > | 19 | (*fun_ptr)(int_ptr); > > | | ^~~~~~~~~~~~~~~~~~~ > > | | | > > | | (6) returning to 'double-call' from 'fun' > > | 20 | (*fun_ptr)(int_ptr); > > | | ^~~~~~~~~~~~~~~~~~~ > > | | | > > | | (7) calling 'fun' from 'double-call' > > | > > +--> 'fun': events 8-9 > > | > > | 4 | void fun(int *int_ptr) > > | | ^~~ > > | | | > > | | (8) entry to ‘fun’ > > | 5 | { > > | 6 | free(int_ptr); > > | | ~~~~~~~~~~~~~ > > | | | > > | | (9) second 'free' here; first 'free' was > > at (5) > > > > The events are created in diagnostic-manager.cc > > > > Am I right in thinking that there's a interprocedural superedge for > > the > > dynamically-discovered calls? > > No there isn’t, such calls will only have an exploded edge and no > interprocedural superedge > > > > > diagnostic_manager::add_events_for_superedge creates events for > > calls > > and returns, so maybe you just need to update the case > > SUPEREDGE_INTRAPROCEDURAL_CALL there, to do something for the > > "dynamically discovered edge" cases (compare it with the other > > cases in > > that function). You might need to update the existing call_event > > and > > return_event subclasses slightly (see checker-path.cc/h) > > As we already have exploded edges representing the call, my idea was > to add event for such cases via custom edge info ( similar to what we > have for longjmp case ) instead of creating a special case in > diagnostic_manager::add_events_for_superedge (). That sounds like it could work too. Dave > > > > > Ideally, event (7) above would read > > "passing freed pointer 'int_ptr' in call to 'fun from > > 'double_call" > > but that's advanced material :) > > > > [...snip...] > > > > Hope this makes sense and is constructive > > Dave > > Thanks > - Ankur >
