On Tue, 2021-06-15 at 19:42 +0530, Ankur Saini wrote: > > > > On 13-Jun-2021, at 8:22 PM, David Malcolm <dmalc...@redhat.com> > > wrote: > > > > On Sun, 2021-06-13 at 19:11 +0530, Ankur Saini wrote: > > > > > > > > > > On 08-Jun-2021, at 11:24 PM, David Malcolm > > > > <dmalc...@redhat.com <mailto:dmalc...@redhat.com>> > > > > wrote: > > > > > > > > Is there a URL for your branch? > > > > > > no, currently it only local branch on my machine. Should I upload > > > it on > > > a hosting site ( like GitHub ) ? or can I create a branch on remote > > > also ? > > > > At some point we want you to be able to push patches to trunk, so as > > a > > step towards that I think it would be good for you to have a personal > > branch on the gcc git repository. > > > > A guide to getting access is here: > > https://gcc.gnu.org/gitwrite.html < > > https://gcc.gnu.org/gitwrite.html> > > > > I will sponsor you. > > I have filled the form.
Thanks. I've clicked on the "Approve" button; presumably we now need to wait for an admin to make this happen. [...] > > > > > > Great. > > > > Let me know how you get on. > > > > As I understand it, Google recommends that we're exchanging emails > > about our GSoC project at least two times a week, so please do > > continue > > to report in, whether you're making progress, or if you feel you're > > stuck on something. > > ok I would be more active from now on. Yes please. > > — > > btw while using the gdb on “xgcc”, for some reason, debugger is not > tracing the call to "run_checkers()” and is directly jumping from > "pass_analyzer::execute()” to some instruction inside > "ana::dump_analyzer_json()”. > > I am invoking debugger like this :- > > — > $ ./xgcc /Users/ankursaini/Desktop/test.c -fanalyzer -B . -wrapper > gdb,—args > — > > and then while putting a breakpoint on “ana::run_checkers()”, gdb > places 2 breakpoints ( one on correct position and another weirdly > inside a different function in the same file ) > > — > (gdb) br ana::run_checkers() > Breakpoint 3 at 0x101640990 (2 locations) > > (gdb) info br > Num Type Disp Enb Address What > 1 breakpoint keep y 0x000000010174ade7 in > fancy_abort(char const*, int, char const*) at ../../gcc- > source/gcc/diagnostic.c:1915 > 2 breakpoint keep y 0x000000010174ee01 in > internal_error(char const*, ...) at ../../gcc- > source/gcc/diagnostic.c:1835 > > 3 breakpoint keep y <MULTIPLE> > 3.1 y 0x0000000101640990 > <ana::dump_analyzer_json(ana::supergraph const&, ana::exploded_graph > const&)+48> > 3.2 y 0x0000000101640ba0 in > ana::run_checkers() at ../../gcc-source/gcc/analyzer/engine.cc:4918 > <http://engine.cc:4918/> > — > > but during the execution it only hits the breakpoint 3.1 ( which is > inside the function "ana::dump_analyzer_json()” which according to me > is called during the execution of "impl_run_checkers()”, after > completing the analysis to dump the results in json format ) > > after looking at backtrace, I could see it calling > "pass_analyzer::execute()” where “run_checkers()” should be called, > but no such call (or a call to "impl_run_checkers()”) is seen there > . > > here is the backtrace when debugger hits this breakpoint 3.1 > — > (gdb) c > Continuing. > [New Thread 0x1c17 of process 2392] > > Thread 2 hit Breakpoint 3, 0x0000000101640990 in > ana::dump_analyzer_json (sg=..., eg=...) at ../../gcc- > source/gcc/analyzer/engine.cc:4751 > 4751 char *filename = concat (dump_base_name, > ".analyzer.json.gz", NULL); > > (gdb) bt > #0 0x0000000101640990 in ana::dump_analyzer_json (sg=..., eg=...) at > ../../gcc-source/gcc/analyzer/engine.cc:4751 > #1 0x000000010161a919 in (anonymous > namespace)::pass_analyzer::execute (this=0x142b0a660) at ../../gcc- > source/gcc/analyzer/analyzer-pass.cc:87 > #2 0x000000010106319c in execute_one_pass (pass=<optimized out>, > pass@entry=<opt_pass* 0x0>) at ../../gcc-source/gcc/passes.c:2567 > #3 0x0000000101064e1c in execute_ipa_pass_list (pass=<opt_pass* > 0x0>) at ../../gcc-source/gcc/passes.c:2996 > #4 0x0000000100a89065 in symbol_table::output_weakrefs > (this=<optimized out>) at ../../gcc-source/gcc/cgraphunit.c:2262 > #5 0x0000000102038600 in ?? () > #6 0x0000000000000000 in ?? () > — > > but at the end I can see the analyzer doing it’s work and generating > the required warning as intended. > > I never used to experience this problem earlier when using debugger > on a full bootstrapped build. Looks like I am missing something here. You're passing -wrapper gdb,--args when compiling a .c file, so gdb is debugging the "cc1" invocation, of the cc1 in the "gcc" subdirectory. gdb is using the debuginfo embedded in the cc1 binary to locate functions, decode expressions, etc. (the debuginfo is probably in DWARF format, embedded in a section of an ELF-formatted binary file). If you're doing a full bootstrap build, then the gcc subdirectory and its cc1 are the "3rd stage". This 3rd stage was built using the 2nd stage's xgcc/cc1plus, and thus the debuginfo inside the cc1 was built using the 2nd stage cc1plus, and thus the debuginfo was generated according to the latest code in GCC. If you're not doing a bootstrap build, then the gcc subdirectory and its cc1 is a "1st stage" build - built using the system compiler, which might be generating different debuginfo. Are you perhaps building the first stage using clang, or a very old gcc? That would likely generate very different debuginfo, which might explain the differences in behavior that you're seeing in gdb. If I run into problems using gdb to debug the code, and all else fails, I sometimes hack up the build flags in the generated Makefile to turn off optimizations and add debug flags. Hope this makes sense Dave
