From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E79C63858C39; Wed, 6 Oct 2021 15:09:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E79C63858C39 From: "peter.weber at flapflap dot eu" To: gdb-prs@sourceware.org Subject: [Bug exp/28428] New: Global variable is always null Date: Wed, 06 Oct 2021 15:09:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: exp X-Bugzilla-Version: 11.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: peter.weber at flapflap dot eu X-Bugzilla-Status: UNCONFIRMED 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 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 Oct 2021 15:09:59 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28428 Bug ID: 28428 Summary: Global variable is always null Product: gdb Version: 11.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: exp Assignee: unassigned at sourceware dot org Reporter: peter.weber at flapflap dot eu Target Milestone: --- Created attachment 13709 --> https://sourceware.org/bugzilla/attachment.cgi?id=3D13709&action=3Ded= it optarg Hello! I'm using GNU getopt[1] and during debugging the global variable 'char * optarg' always prints 0x00 i.e. nullptr. While the variable actually contai= ns a valid pointer address as a value. Upon assignment, the correct value is therefore used and the program executes well in defined behavior. My expectation is, that GDB shows the same value as is used by the actual prog= ram in execution. I'm using Archlinux with GCC 11.1 and GDB 11.1. The attachment contains a sample code. Steps to reproduce: ---------------------------------------------------------------------------= ----- $ gcc -o getopt getopt.c -g # debugging ON, optimizations OFF $ gdb getopt (gdb) b 26 # set breakpoint (gdb) r -cfoo (gdb) p optarg $1 =3D 0x0 # no "foo"? (gdb) n # executes cvalue =3D optarg (gdb) p cvalue $2 =3D 0x7fffffffea99 "foo" # here it is, please don't expect to get the sa= me memory-address ---------------------------------------------------------------------------= ----- When I stop the execution on line 26 and print 'optarg' I receive 0x00. Whe= n I step further to line 28 and print 'cvalue' it contains the passed command l= ine parameter value. The 'optarg' still shows 0x00 as a value. I figured out th= at a syntax which is used to refer to hidden variables or similar[3] can be used= as a workaround: p (char*)'optarg@GLIBC_2.2.5' I figured that out during reading other C++-related questions and playing w= ith tab completion in GDB. For further info, you can read the corresponding question at Stackoverflow[2].=20 Do I make something wrong? Is this a bug? Thank you Peter [1] https://www.gnu.org/software/libc/manual/html_node/Using-Getopt.html [2] https://stackoverflow.com/q/69409047/1054324 [3] https://sourceware.org/gdb/current/onlinedocs/gdb/Variables.html --=20 You are receiving this mail because: You are on the CC list for the bug.=