From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id BF6FC3851C0D for ; Wed, 13 May 2020 15:46:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BF6FC3851C0D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.193] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 19DF61E5F9; Wed, 13 May 2020 11:46:49 -0400 (EDT) Subject: Re: [PATCH v2 00/42] Share DWARF partial symtabs between objfiles To: Tom de Vries , Simon Marchi , gdb-patches@sourceware.org References: <20200512210913.5593-1-simon.marchi@efficios.com> From: Simon Marchi Message-ID: Date: Wed, 13 May 2020 11:46:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 15:46:51 -0000 On 2020-05-13 6:17 a.m., Tom de Vries wrote: > On 12-05-2020 23:08, Simon Marchi via Gdb-patches wrote: >> This is version 2 of this patchset originally written by Tom: >> >> https://sourceware.org/legacy-ml/gdb-patches/2020-02/msg00594.html >> >> The current patchset therefore contains a mix of Tom's patches that I modified, >> plus a few new patches. I won't repeat everything that is said in the cover >> letter of that patchset, please read that to understand the motivation behind >> this change.. >> >> The big difference between v1 and v2 is how the split is done. In v1, the >> object structure looks like this: >> >> objfile -> dwarf2_per_objfile -> dwarf2_unshareable >> >> where `dwarf2_per_objfile` is actually shared between objfiles (there is one >> copy per BFD), and `dwarf2_unshareable` is not (there is one copy per objfile). >> The dwarf2_per_objfile -> dwarf2_unshareable link is updated at all entry >> points of the DWARF code based on what is the current objfile. >> >> The current patchset (v2) proposes this structure instead, which in my opinion >> is more natural: >> >> objfile -> dwarf2_per_objfile -> dwarf2_per_bfd >> >> Where `dwarf2_per_objfile` is really per-objfile (there is one copy per >> objfile) and `dwarf2_per_bfd` is per-bfd (there is one copy per-bfd). There is >> no link to update, whatever is shared between objfiles is put in >> `dwarf2_per_bfd` and each `dwarf2_per_objfile` always points to one >> `dwarf2_per_bfd`. >> >> Since there were performance numbers with the original patchset, I made my own >> here to see if the speedups were still there. Like in the original patchset, I >> set "maintenance time 1" and did "add-inferior -exec ./gdb" after "./gdb gdb". >> I disabled any auto-loading to avoid loading gdb-gdb.{gdb,py}. GDB is built >> with -O2 and gcc 9, and it is running on an AMD EPYC 7351P. >> >> Before: Command execution time: 1.213480 (cpu), 1.214268 (wall) >> After: Command execution time: 0.001697 (cpu), 0.001694 (wall) >> >> These are the times of one run, but all runs I did are very close. The "after" >> time is surpringly low compared to the original numbers, I hope it doesn't mean >> I messed up something and we are skipping something important... >> >> At some point I tested with all these boards and did not see any regression >> (they helped very much to find some issues in the process though): >> >> unix cc-with-debug-names cc-with-dwz cc-with-dwz-m cc-with-gdb-index dwarf4-gdb-index fission-dwp fission readnow >> >> I have since rebased the patchset and resolved conflicts, it's therefore >> possible I messed something up. >> > > Hi, I applied the patch series on top of commit 90d00bbd9c "Sync config > and libiberty with GCC", and ran into the following: > ... > (gdb) PASS: gdb.ada/variant.exp: scenario=minimal: print nav1 > print nav2^M > ERROR: GDB process no longer exists > GDB process exited with wait status 8901 exp9 0 0 CHILDKILLED SIGABRT > SIGABRT > UNRESOLVED: gdb.ada/variant.exp: scenario=minimal: print nav2 > ... > > Reproduced on command line using: > ... > $ gdb -batch ./outputs/gdb.ada/variant/pkg \ > -ex 'break pkg.adb:40' \ > -ex run \ > -ex 'print nav2' > Breakpoint 1 at 0x403047: file gdb/testsuite/gdb.ada/variant/pkg.adb, > line 40. > > Breakpoint 1, pkg () at gdb/testsuite/gdb.ada/variant/pkg.adb:40 > 40 null; -- STOP > Aborted (core dumped) > ... > > Using gdb, we get more info: > ... > Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. > 0x00000000005b9d02 in dwarf2_locexpr_baton_eval (dlbaton=0x7fffffffc608, > frame=0x15c75f0, > addr_stack=0x7fffffffc790, valp=0x7fffffffc638, push_initial_value=true) > at /data/gdb_versions/devel/src/gdb/dwarf2/loc.c:2490 > 2490 ctx.gdbarch = per_objfile->objfile->arch (); > ... > > The problem seems to be: > ... > (gdb) p per_objfile > $1 = (dwarf2_per_objfile *) 0xffffffffffffffff > ... > > Backtrace: > ... > (gdb) bt > #0 0x00000000005b9d02 in dwarf2_locexpr_baton_eval > (dlbaton=0x7fffffffc608, frame=0x15c75f0, > addr_stack=0x7fffffffc790, valp=0x7fffffffc638, push_initial_value=true) > at /data/gdb_versions/devel/src/gdb/dwarf2/loc.c:2490 > #1 0x00000000005ba007 in dwarf2_evaluate_property (prop=0x7fffffffc640, > frame=0x15c75f0, > addr_stack=0x7fffffffc790, value=0x7fffffffc638, > push_initial_value=true) > at /data/gdb_versions/devel/src/gdb/dwarf2/loc.c:2562 > #2 0x0000000000672aff in resolve_dynamic_struct (type=0x1b25660, > addr_stack=0x7fffffffc790) > at /data/gdb_versions/devel/src/gdb/gdbtypes.c:2480 > #3 0x000000000067309c in resolve_dynamic_type_internal (type=0x1b25660, > addr_stack=0x7fffffffc790, top_level=1) > at /data/gdb_versions/devel/src/gdb/gdbtypes.c:2613 > #4 0x0000000000673225 in resolve_dynamic_type (type=0x1b25660, > valaddr=..., addr=4255376) > at /data/gdb_versions/devel/src/gdb/gdbtypes.c:2649 > #5 0x00000000009b1918 in value_from_contents_and_address > (type=0x1b25660, valaddr=0x0, address=4255376) > at /data/gdb_versions/devel/src/gdb/value.c:3483 > #6 0x0000000000999f9c in get_value_at (type=0x1b25660, addr=4255376, > lazy=1) > at /data/gdb_versions/devel/src/gdb/valops.c:899 > #7 0x000000000099a00a in value_at_lazy (type=0x1b25660, addr=4255376) > at /data/gdb_versions/devel/src/gdb/valops.c:936 > #8 0x000000000064dc01 in default_read_var_value (var=0x1b256c0, > var_block=0x1b25760, frame=0x0) > at /data/gdb_versions/devel/src/gdb/findvar.c:800 > #9 0x000000000043a2f2 in ada_read_var_value (var=0x1b256c0, > var_block=0x1b25760, frame=0x0) > at /data/gdb_versions/devel/src/gdb/ada-lang.c:14061 > #10 0x000000000064dccd in read_var_value (var=0x1b256c0, > var_block=0x1b25760, frame=0x0) > at /data/gdb_versions/devel/src/gdb/findvar.c:815 > #11 0x000000000099acf3 in value_of_variable (var=0x1b256c0, b=0x1b25760) > --Type for more, q to quit, c to continue without paging-- > at /data/gdb_versions/devel/src/gdb/valops.c:1293 > #12 0x000000000062ddd8 in evaluate_var_value > (noside=EVAL_AVOID_SIDE_EFFECTS, blk=0x1b25760, var=0x1b256c0) > at /data/gdb_versions/devel/src/gdb/eval.c:716 > #13 0x000000000062f4e3 in evaluate_subexp_standard (expect_type=0x0, > exp=0x1bcf8c0, pos=0x7fffffffd1c4, > noside=EVAL_AVOID_SIDE_EFFECTS) at > /data/gdb_versions/devel/src/gdb/eval.c:1319 > #14 0x000000000043232e in ada_evaluate_subexp (expect_type=0x0, > exp=0x1bcf8c0, pos=0x7fffffffd1c4, > noside=EVAL_AVOID_SIDE_EFFECTS) at > /data/gdb_versions/devel/src/gdb/ada-lang.c:10656 > #15 0x000000000062ca12 in evaluate_subexp (expect_type=0x0, > exp=0x1bcf8c0, pos=0x7fffffffd1c4, > noside=EVAL_AVOID_SIDE_EFFECTS) at > /data/gdb_versions/devel/src/gdb/eval.c:77 > #16 0x000000000042f787 in evaluate_subexp_type (exp=0x1bcf8c0, > pos=0x7fffffffd1c4) > at /data/gdb_versions/devel/src/gdb/ada-lang.c:9417 > #17 0x0000000000423e80 in resolve_subexp (expp=0x7fffffffd418, > pos=0x7fffffffd1c4, deprocedure_p=1, > context_type=0x0, parse_completion=0, tracker=0x7fffffffd2f0) > at /data/gdb_versions/devel/src/gdb/ada-lang.c:3826 > #18 0x0000000000422fd2 in resolve (expp=0x7fffffffd418, > void_context_p=0, parse_completion=0, > tracker=0x7fffffffd2f0) at > /data/gdb_versions/devel/src/gdb/ada-lang.c:3463 > #19 0x00000000007bd06c in parse_exp_in_context > (stringptr=0x7fffffffd3d0, pc=0, block=0x0, comma=0, > void_context_p=0, out_subexp=0x0, tracker=0x7fffffffd2f0, cstate=0x0) > at /data/gdb_versions/devel/src/gdb/parse.c:1149 > #20 0x00000000007bcd28 in parse_exp_1 (stringptr=0x7fffffffd3d0, pc=0, > block=0x0, comma=0, tracker=0x0) > at /data/gdb_versions/devel/src/gdb/parse.c:1031 > #21 0x00000000007bd1cf in parse_expression (string=0x7fffffffe0fb > "nav2", tracker=0x0) > at /data/gdb_versions/devel/src/gdb/parse.c:1167 > #22 0x00000000007c04b6 in print_command_1 (args=0x7fffffffe0fb "nav2", > voidprint=1) > at /data/gdb_versions/devel/src/gdb/printcmd.c:1214 > --Type for more, q to quit, c to continue without paging-- > #23 0x00000000007c062c in print_command (exp=0x7fffffffe0fb "nav2", > from_tty=0) > at /data/gdb_versions/devel/src/gdb/printcmd.c:1244 > #24 0x00000000004fdf16 in do_const_cfunc (c=0x19cca60, > args=0x7fffffffe0fb "nav2", from_tty=0) > at /data/gdb_versions/devel/src/gdb/cli/cli-decode.c:107 > #25 0x000000000050103f in cmd_func (cmd=0x19cca60, args=0x7fffffffe0fb > "nav2", from_tty=0) > at /data/gdb_versions/devel/src/gdb/cli/cli-decode.c:2004 > #26 0x000000000091bcf5 in execute_command (p=0x7fffffffe0fe "2", from_tty=0) > at /data/gdb_versions/devel/src/gdb/top.c:655 > #27 0x0000000000746633 in catch_command_errors (command=0x91b889 > , > arg=0x7fffffffe0f5 "print nav2", from_tty=0) at > /data/gdb_versions/devel/src/gdb/main.c:457 > #28 0x0000000000747a1b in captured_main_1 (context=0x7fffffffd9e0) > at /data/gdb_versions/devel/src/gdb/main.c:1219 > #29 0x0000000000747c10 in captured_main (data=0x7fffffffd9e0) at > /data/gdb_versions/devel/src/gdb/main.c:1244 > #30 0x0000000000747c7b in gdb_main (args=0x7fffffffd9e0) at > /data/gdb_versions/devel/src/gdb/main.c:1269 > #31 0x000000000041520e in main (argc=14, argv=0x7fffffffdae8) at > /data/gdb_versions/devel/src/gdb/gdb.c:32 Thanks for the report. We were missing assigning dlbaton->per_objfile in handle_data_member_location. This is some recent code on which I rebased just before sending the series. Good thing I included that disclaimer :). I fixed it in patch 4, "Add dwarf2_per_objfile member to DWARF batons". Simon