From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 63A113858438; Wed, 27 Mar 2024 02:10:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 63A113858438 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1711505420; bh=mIeLczm1rHTKE9ocI8iP04kGfxHME+jOa1RhaQUJMD0=; h=From:To:Subject:Date:From; b=AVy0/J/Ek1iymK8ml17VII3qDiEy8ADu7AFhW+ssbEVvNxQ+tCXNoIvSghjBYGET3 AA2tyBtHyUGOYA38F5TqQfel8lL8Lz+wNzEmKn5tacja/kKlszvGXvG6xxZ4hULq4f Be6m9vqu7sfPPKYBF8+zq1yvUbHkXlmvyef3WJMo= From: "kevinb at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/31563] New: Problems with accessing errno Date: Wed, 27 Mar 2024 02:10:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new 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: kevinb at redhat dot com 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: 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 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31563 Bug ID: 31563 Summary: Problems with accessing errno Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: kevinb at redhat dot com Target Milestone: --- Created attachment 15437 --> https://sourceware.org/bugzilla/attachment.cgi?id=3D15437&action=3Ded= it C program for demonstrating problems w/ errno I am writing a new gdb test, gdb.base/check-errno.exp. (Actually, it's a rewrite of an old test written by Jan Kratochvil from a while back, perhaps= as far back as 2008.) The test compiles a simple program multiple times, each = time using different compile flags. In some cases, GDB is able to print errno correctly and in other cases it does not. The program is named check-errno.= c. Here are the instances where GDB is unable to access errno: 1) -static: kev@f39-1:ce$ gcc -static -g -o check-errno-static check-errno.c=20 kev@f39-1:ce$ $GDB -q check-errno-static Reading symbols from check-errno-static... (gdb) b 24 Breakpoint 1 at 0x401794: file check-errno.c, line 24. (gdb) run Starting program: /tmp/ce/check-errno-static=20 This GDB supports auto-downloading debuginfo from the following URLs: Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. Downloading separate debug info for system-supplied DSO at 0x7ffff7ffd000 Breakpoint 1, main () at check-errno.c:24 24 return 0; /* breakpoint */ (gdb) p errno Cannot find thread-local storage for process 14409, executable file /tmp/ce/check-errno-static: Cannot find thread-local variables on this target 2) -static -g3: kev@f39-1:ce$ gcc -static -g3 -o check-errno-static check-errno.c=20 kev@f39-1:ce$ $GDB -q check-errno-static Reading symbols from check-errno-static... (gdb) b 24 Breakpoint 1 at 0x401794: file check-errno.c, line 24. (gdb) run Starting program: /tmp/ce/check-errno-static=20 This GDB supports auto-downloading debuginfo from the following URLs: Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. Breakpoint 1, main () at check-errno.c:24 24 return 0; /* breakpoint */ (gdb) p errno '__errno_location' has unknown return type; cast the call to its declared return type 3, 4) Same as above, but use gcore to make a core file for above two cases. 5) -lpthread -g3, from corefile: kev@f39-1:ce$ gcc -lpthreads -g3 -o check-errno-pthreads-g3 check-errno.c=20 /usr/bin/ld: cannot find -lpthreads: No such file or directory collect2: error: ld returned 1 exit status kev@f39-1:ce1$ gcc -lpthread -g3 -o check-errno-pthreads-g3 check-errno.c=20 kev@f39-1:ce$ $GDB -q check-errno-pthreads-g3 Reading symbols from check-errno-pthreads-g3... (gdb) b 24 Breakpoint 1 at 0x401135: file check-errno.c, line 24. (gdb) run Starting program: /tmp/ce/check-errno-pthreads-g3=20 This GDB supports auto-downloading debuginfo from the following URLs: Enable debuginfod for this session? (y or [n]) y Debuginfod has been enabled. To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, main () at check-errno.c:24 24 return 0; /* breakpoint */ (gdb) p errno $1 =3D 42 (gdb) gcore check-errno-pthreads-gc.core warning: Memory read failed for corefile section, 4096 bytes at 0xffffffffff600000. Saved corefile check-errno-pthreads-gc.core (gdb) core check-errno-pthreads-gc.core A program is being debugged already. Kill it? (y or n) y [New LWP 14550] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/tmp/ce/check-errno-pthreads-g3'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 main () at check-errno.c:24 24 return 0; /* breakpoint */ (gdb) p errno You can't do that without a process to debug. The above behavior was observed on Fedora 39, which is using the following version of gcc: gcc (GCC) 13.2.1 20240316 (Red Hat 13.2.1-7) Fedora GDB has a hack which causes errno to be printed correctly for each of these cases. However, IMO, it truly is a hack and is not acceptable for upstream. I would like to figure out and fix (if possible) the root cause = of each of the problems above so that the hack may be discarded. --=20 You are receiving this mail because: You are on the CC list for the bug.=