From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 551CB3B8A415; Fri, 7 May 2021 12:40:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 551CB3B8A415 From: "luis.machado at linaro dot org" To: gdb-prs@sourceware.org Subject: [Bug gdb/27826] 10000 timeouts running the testsuite on arm-linux-gnueabihf Date: Fri, 07 May 2021 12:40:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: luis.machado at linaro dot org X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: luis.machado at linaro dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to 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: Fri, 07 May 2021 12:40:08 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27826 Luis Machado changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |WAITING Assignee|unassigned at sourceware dot org |luis.machado at lin= aro dot org --- Comment #2 from Luis Machado --- After investigating this, the root cause of the timeouts is caused by GDB u= sing the wrong type of breakpoint (between a 4 bytes ARM breakpoint and a 2 bytes thumb breakpoint), which causes some unexpected results. The reason why this is happening is a bit more complex though. GDB has a co= uple mechanisms for tracking loading/unloading of shared libraries in dynamically-linked binaries. Via _dl_debug_state and r_brk and via stap pro= bes. Up until Ubuntu 18.04 (glibc 2.27), GDB could not use the stap probes mecha= nism because it ran into a bug when parsing stap expression, thus failing the ch= eck and falling back to using the old _dl_debug_state and r_brk mechanism. The _dl_debug_state/r_brk mechanism works because we have an entry for _dl_debug_state in the .dynsym section of ld.so. Even though ld.so is completely stripped of mapping symbols (another way to tell arm/thumb modes apart), which are only available via the debug symbols file, GDB can still = tell _dl_debug_state is arm or thumb mode because the ELF symbol carries a flag indicating so. That's why this fallback mechanism works. On Ubuntu 20.04, running glibc 2.31, GDB no longer runs into problems with = stap probes. Thus GDB decides to use this mechanism instead of the old _dl_debug_state/r_brk one. Both mechanisms function by having GDB insert breakpoints at specific locat= ion so shared library events can be tracked. But in the stap probes case there = are no real symbols. What we have is metadata that contains the name of the probe and its addres= s. This address falls within a particular function. For example, init_start and init_complete are probe points that fall within dl_main. The probe points do not seem to carry any information about whether we have arm or thumb mode. As before, the mapping symbols should tell us what the mode is, but ld.so is stripped and doesn't carry those. But GDB could look at the ELF symbol of t= he function the probe is sitting at, except that these symbols (not considered special in any way) have been stripped as well. So the arm/thumb informatio= n is completely gone and GDB can no longer make the correct decision. So GDB defaults to assuming arm mode for the breakpoint to use, which is obviously wrong for thumb code. There are two possible solutions: 1 - Fallback to using _dl_debug_state/r_brk for armhf in GDB. This is considered bad by GDB's maintainers, because it means using an outdated mechanism instead of better interfaces. 2 - Don't strip glibc/ld.so function symbols that have stap probes installe= d in them. Right now, these are the functions that contain probes and that GDB wants to breakpoint in a special way: _dl_main, _dl_map_object_from_fd, lose, dl_open_worker and _dl_close_worker --=20 You are receiving this mail because: You are on the CC list for the bug.=