From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D3CD138515DD; Mon, 31 May 2021 17:06:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D3CD138515DD From: "bernd.edlinger at hotmail dot de" To: gdb-prs@sourceware.org Subject: [Bug breakpoints/26096] gdb sets breakpoint at cold clone Date: Mon, 31 May 2021 17:06:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: breakpoints X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bernd.edlinger at hotmail dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2021 17:06:51 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26096 Bernd Edlinger changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernd.edlinger at hotmail = dot de --- Comment #6 from Bernd Edlinger --- (In reply to Tom de Vries from comment #3) > Another thing I noticed with cold clones: > ... > $ gdb -q -batch a.out -ex "maint print psymbols" | egrep "foo|bar" > `bar', function, 0x400455 > `foo', function, 0x400450 > ... >=20 > The psymbol address of the function bar is the address of "bar() [clone > .cold]". >=20 > Presumably we'd want the entry address here. >=20 > Looking at the corresponding DWARF, we have: > ... > <1><990>: Abbrev Number: 35 (DW_TAG_subprogram) > <991> DW_AT_name : foo > <995> DW_AT_decl_file : 1 > <996> DW_AT_decl_line : 8 > <997> DW_AT_decl_column : 1 > <998> DW_AT_type : <0x39b> > <99c> DW_AT_ranges : 0x40 > <9a0> DW_AT_frame_base : 1 byte block: 9c=20=20=20=20=20=20=20 > (DW_OP_call_frame_cfa) > <9a2> DW_AT_GNU_all_call_sites: 1 > <9a2> DW_AT_sibling : <0x9b4> > ... >=20 > In DWARF 4 standard 2.18 Entry Address we read: > ... > If no DW_AT_entry_pc attribute is present, then the entry address is assu= med > to be the same as the value of the DW_AT_low_pc attribute, if present; > otherwise, the entry address is unknown. > ... >=20 > In this case, we have no DW_AT_entry_pc and no DW_AT_low_pc attribute.=20 > Arguably, this is a gcc bug. >=20 > Either way, in absence of a fix in gcc for this, we could adapt a > interpretation that the entry pc is the start address of the first range.= At > least, this works for this exec: > ... > 00000070 00000000004005b0 00000000004005d7 > 00000070 0000000000400455 000000000040045a > 00000070 > ... >=20 > This also seems to be the current interpretation for full symtabs, AFAIU > from the comment for BLOCK_ENTRY_PC in block.h: > ... > /* Define the "entry pc" for a block BL to be the lowest (start) address= =20=20=20=20 >=20 > for the block when all addresses within the block are contiguous. If= =20=20=20=20 >=20 > non-contiguous, then use the start address for the first range in the= =20=20=20=20 >=20 > block.=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20 > ... This is related to this patch: https://sourceware.org/pipermail/gdb-patches/2021-May/179369.html --=20 You are receiving this mail because: You are on the CC list for the bug.=