From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 695D939484B4; Wed, 6 Jan 2021 13:53:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 695D939484B4 From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug breakpoints/27151] Step will skip subsequent statements for malloc functions Date: Wed, 06 Jan 2021 13:53:38 +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: vries at gcc dot gnu.org 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: 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: Wed, 06 Jan 2021 13:53:38 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27151 --- Comment #6 from Tom de Vries --- This is slightly more convoluted. I tried to reproduce the problem on openSUSE Factory. Using -fcf-protection=3Dfull, there I managed to get a .plt.sec section. But gdb handled it ok. It did not take the "stepped into dynsym resolve code" path, but handled th= ings fine along another path. So I debugged once more the ubuntu exec on leap. I found that at some poin= t we do: ... /* If we are in a function call trampoline (a stub between the=20=20= =20=20=20=20=20=20=20=20=20=20 calling routine and the real function), locate the real=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 function. That's what tells us (a) whether we want to step=20=20= =20=20=20=20=20=20=20=20=20=20 into it at all, and (b) what prologue we want to run to the=20=20= =20=20=20=20=20=20=20=20=20=20 end of, if we do step into it. */ real_stop_pc =3D skip_language_trampoline (frame, stop_pc); ... and end up in objc_language::skip_trampoline, and then in gdbarch_skip_trampoline_code, and then in find_solib_trampoline_target: ... /* If PC is in a shared library trampoline code stub, return the=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 address of the `real' function belonging to the stub.=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Return 0 if PC is not in a trampoline code stub or if the real=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 function is not found in the minimal symbol table.=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 We may fail to find the right function if a function with the=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 same name is defined in more than one shared library, but this=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20 is considered bad programming style. We could return 0 if we find=20=20= =20=20=20=20=20=20=20=20=20 a duplicate function in case this matters someday. */ CORE_ADDR find_solib_trampoline_target (struct frame_info *frame, CORE_ADDR pc) { struct minimal_symbol *tsymbol =3D lookup_solib_trampoline_symbol_by_pc (= pc); if (tsymbol !=3D NULL) { for (objfile *objfile : current_program_space->objfiles ()) { for (minimal_symbol *msymbol : objfile->msymbols ()) { ... So, we find that the pc is a trampoline for malloc, and start iterating over the minsyms in the objfiles. With openSUSE Leap (glibc 2.26), we find this as first match: ... $ nm /lib64/ld-linux-x86-64.so.2 | grep malloc 0000000000019710 W malloc ... With openSUSE Factory (glibc 2.32), we have instead rtld_malloc so skip_language_trampoline returns 0. --=20 You are receiving this mail because: You are on the CC list for the bug.=