"optimized out" in spite of DWARF saying otherwise?

"optimized out" in spite of DWARF saying otherwise?

[Michael Haupt]

Hi,

so I have this formal argument to a method, and my DWARF says

0x...e642 - 0x...e642: rdi

(note start and end are the same). gdb, however, insists on the value being "<optimized out>", with the current address being 0x...e642. How is this?

Best,

Michael

-- 
Dr. Michael Haupt
Principal Member of Technical Staff
Phone: +49 331 200 7277, Fax: +49 331 200 7561
Oracle Labs
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14, 14467 Potsdam, Germany
From gdb-return-41940-listarch-gdb=sources.redhat.com@sourceware.org Thu Mar 21 16:45:11 2013
Return-Path: <gdb-return-41940-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 23649 invoked by alias); 21 Mar 2013 16:45:10 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 23632 invoked by uid 89); 21 Mar 2013 16:45:04 -0000
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
Received: from mout1.freenet.de (HELO mout1.freenet.de) (195.4.92.91)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 21 Mar 2013 16:45:01 +0000
Received: from [195.4.92.140] (helo=mjail0.freenet.de)	by mout1.freenet.de with esmtpa (ID ralf.corsepius@freenet.de) (port 25) (Exim 4.80.1 #2)	id 1UIibo-0000TI-Tr; Thu, 21 Mar 2013 17:44:56 +0100
Received: from localhost ([::1]:57482 helo=mjail0.freenet.de)	by mjail0.freenet.de with esmtpa (ID ralf.corsepius@freenet.de) (Exim 4.80.1 #2)	id 1UIibo-0006pB-Dr; Thu, 21 Mar 2013 17:44:56 +0100
Received: from [195.4.92.23] (portE795 helo\x13.mx.freenet.de)	by mjail0.freenet.de with esmtpa (ID ralf.corsepius@freenet.de) (Exim 4.80.1 #2)	id 1UIiZ1-0006fF-Ek; Thu, 21 Mar 2013 17:42:03 +0100
Received: from hsi-kbw-109-193-026-150.hsi7.kabel-badenwuerttemberg.de ([109.193.26.150]:43583 helo=[192.168.1.104])	by 13.mx.freenet.de with esmtpsa (ID ralf.corsepius@freenet.de) (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (port 587) (Exim 4.80.1 #2)	id 1UIiZ0-0003C0-TR; Thu, 21 Mar 2013 17:42:03 +0100
Message-ID: <514B3857.2010200@rtems.org>
Date: Thu, 21 Mar 2013 16:45:00 -0000
From: Ralf Corsepius <ralf.corsepius@rtems.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4
MIME-Version: 1.0
To: Joel Sherrill <joel.sherrill@oarcorp.com>
CC: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: sim/mips/config.in
References: <514B28B2.9050603@oarcorp.com>
In-Reply-To: <514B28B2.9050603@oarcorp.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2013-03/txt/msg00064.txt.bz2
Content-length: 334

On 03/21/2013 04:35 PM, Joel Sherrill wrote:
> Hi
>
> I have tripped across an inconsistency while reviewing my patch.
> In sim/mips, configure.ac says it needs autoconf 2.64 but autoheader
> does not generate the same config.in that is in CVS.
>
> Any comments?

The config.in in CVS is outdated. It needs to be regenerated.

Ralf

Re: "optimized out" in spite of DWARF saying otherwise?

[Jan Kratochvil]

On Thu, 21 Mar 2013 17:39:26 +0100, Michael Haupt wrote:
> so I have this formal argument to a method, and my DWARF says
> 
> 0x...e642 - 0x...e642: rdi
> 
> (note start and end are the same). gdb, however, insists on the value being
> "<optimized out>", with the current address being 0x...e642. How is this?

That is correct.  DWARF4:
2. An ending address offset. [...] It marks the first address past the end of
the address range over which the location is valid.

Such entry in fact does not say anything, it covers zero bytes.

(1) You should look on other entries in that location list (if any).

(2) This "weird" entry can be used for so-called "entry-values" resolving.
    Try in GDB "set debug entry-values 1" (before stopping in this function)
    to see more debug information why GDB failed to resolve the parameter.
    I have to recomment FSF GDB HEAD (CVS/GIT) or the 7.6 pre-release, I made
    recently there some entry-values resolving fixes.


Regards,
Jan

Re: "optimized out" in spite of DWARF saying otherwise?

[Michael Haupt]

Jan,

Am 21.03.2013 um 17:48 schrieb Jan Kratochvil <jan.kratochvil@redhat.com>:
> On Thu, 21 Mar 2013 17:39:26 +0100, Michael Haupt wrote:
>> so I have this formal argument to a method, and my DWARF says
>> 
>> 0x...e642 - 0x...e642: rdi
>> 
>> (note start and end are the same). gdb, however, insists on the value being
>> "<optimized out>", with the current address being 0x...e642. How is this?
> 
> That is correct.  DWARF4:
> 2. An ending address offset. [...] It marks the first address past the end of
> the address range over which the location is valid.
> 
> Such entry in fact does not say anything, it covers zero bytes.

thanks for reminding me of a too-long forgotten part of the standard. :-)

> (1) You should look on other entries in that location list (if any).

I generate all of these myself; some of them cover call sites (which are a couple instructions long and never caused this trouble).

The offending one I asked about is just a mark. There is no guarantee as to which instruction there is at the address in question; is it "safe" to use an extent of, say, 1, or does the instruction length govern that?

Best,

Michael
From gdb-return-41943-listarch-gdb=sources.redhat.com@sourceware.org Fri Mar 22 00:30:20 2013
Return-Path: <gdb-return-41943-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 8811 invoked by alias); 22 Mar 2013 00:30:20 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 8694 invoked by uid 89); 22 Mar 2013 00:29:36 -0000
X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD autolearn=ham version=3.3.1
Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 22 Mar 2013 00:29:33 +0000
Received: from vapier.localnet (localhost [127.0.0.1])	by smtp.gentoo.org (Postfix) with ESMTP id A74C133CB84;	Fri, 22 Mar 2013 00:29:31 +0000 (UTC)
From: Mike Frysinger <vapier@gentoo.org>
To: Joel Sherrill <joel.sherrill@oarcorp.com>
Subject: Re: Simulator patches for dv-sockser.o
Date: Fri, 22 Mar 2013 00:30:00 -0000
User-Agent: KMail/1.13.7 (Linux/3.7.6; KDE/4.6.5; x86_64; ; )
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
References: <514B2CE9.2020600@oarcorp.com>
In-Reply-To: <514B2CE9.2020600@oarcorp.com>
MIME-Version: 1.0
Content-Type: multipart/signed;  boundary="nextPart2790790.dPxLp44UoQ";  protocol="application/pgp-signature";  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <201303212033.26504.vapier@gentoo.org>
X-Virus-Found: No
X-SW-Source: 2013-03/txt/msg00067.txt.bz2


--nextPart2790790.dPxLp44UoQ
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-length: 2542

On Thursday 21 March 2013 11:53:13 Joel Sherrill wrote:
> Per conversations with Mike Frysinger, I have made other modifications.
> These basically address:
> 
> + simulators which can't work without dv-sockser.o fail at configuration
> + simulators which fail with --disable-sim-hardware fail at configuration
> + added conditionals and FIXME for dv-sockser.o references in source
> 
> Attached is a tarball from git which has a patch per simulator directory
> touched. The last patch is the regeneration of configure's.
> 
> I have built all of the impacted CPUs with --enable-sim-hardware
> and --disable-sim-hardware.

the main idea looks good to me.  just style nits below.

> 0001-sim-common-acinclude.m4-Address-always-required-hard.patch
>
> +  if test "[$1]" = "always"; then
> +    AC_MSG_ERROR([Sorry, but this simulator requires that hardware support 
be enabled. Please configure without --disable-hw-support.])
> +  fi

that line is too long.  just put a new line in the middle and that should be 
fine (since the output will still look fine).
  AC_MSG_ERROR([...................
............])

> 0002-bfin-configure.ac-Address-use-of-dv-sockser.o.patch
>
> +2013-03-20  Joel Sherrill <joel.sherrill@oarcorp.com>

should be two spaces between your name & e-mail.  you should check all the 
ChangeLog entries accordingly.

> +	* configure.ac: Use $SIM_DV_SOCKSER_O

should have a period at the end.  you should check all the ChangeLog entries 
accordingly.

> 0003-sim-mips-Address-use-of-dv-sockser.o.patch
>
> +		AC_MSG_ERROR([Sorry, but tx3904sio hardware support is unavailable 
for your target.  Please use --disable-sim-hardware, or pass a list of devices 
to enable that does not include that.])

same comment re-too long of a line.

also, i think this indents with a tab instead of two spaces ?  a few of the 
patches have that, so you should grep for tabs to make sure none are left in.

> 0005-frv-configure.ac-Address-use-of-dv-sockser.o.patch
>
> +	AC_MSG_ERROR([Sorry, but hardware support in this simulator 
unconditionally relies on dv-sockser.o, it is unavailable for your host. 
Please fix this simulator.])

same comment about too long.  also, change "..., it is" to "... which is".

> 0006-iq2000-configure.ac-Address-use-of-dv-sockser.o.patch
> 0007-m32r-configure.ac-Address-use-of-dv-sockser.o.patch
> 0008-mn10300-configure.ac-Address-use-of-dv-sockser.o.patch
> 0009-sh64-configure.ac-Address-use-of-dv-sockser.o.patch

same feedback as 0005-frv patch above
-mike

--nextPart2790790.dPxLp44UoQ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
Content-length: 836

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAABAgAGBQJRS6bWAAoJEEFjO5/oN/WBbQQQAIK/TMF5tom9DyMa4tQjH3MD
EGjhkiI0Xz3DeBtYWVFQO0BMY2vkAMA7IAmZUKZYfThVRGzJN+sb42N5f4Nccx4y
Qu0UvZ57UxE7+9ZFOMwUh/QiVnAsvNYcrrH5+bE1rb9MH6FOGeZn8GxSPQrIwKYz
wUiXb/H7mUkDFWBRgPpRoIkXi5j9GLMe60F+ZOcXBDrCiqsIxP02jbePqpRoBQiD
rxKph84/A25qLztAekwb/R63Se+M0N7RnIv1RjYo5+Y/XqJka/gFC1mJfS6HSWbl
LCar25LdYE45jQCowCNC1EDhw7fVYdB4d4bni/NIzuinnKkhgDCZCjdv0mpIsIo4
p/WCvHllCpJRCzJsEZMSK+cLVWwCWBB1KaF9mnPdvFeH9X8YwU3JcXi4/66SITW6
RTLdq2Z3wRih9v5gD2cnskFn1UyE9LUYmKFznZ3bZ6bt8oJao8SzGSn0RsjLDiHa
mC4GRlSCnDYmWCwSNEvj/XnqhcUaeH19FVu5inZ6R47CT+mA9U/aGPYjFmgcmrmP
ERexUp3XLlUHGKOdDczyuDH3Sw1b2TY3CMPVufQb3bTiSVp1TK1yEQO1A8vnil5t
RCvN38U4rYo2q3hAHhQfkS8MCmVO2uVUsHtkJsZ2nY/0earMT65QzkI2fL8iPl/X
2HMJSQUcH5Zf7bq13PKA
=0n4b
-----END PGP SIGNATURE-----

--nextPart2790790.dPxLp44UoQ--

Re: "optimized out" in spite of DWARF saying otherwise?

[Jan Kratochvil]

On Thu, 21 Mar 2013 21:15:20 +0100, Michael Haupt wrote:
> The offending one I asked about is just a mark. There is no guarantee as to
> which instruction there is at the address in question; is it "safe" to use
> an extent of, say, 1, or does the instruction length govern that?

At least for GDB it is OK to use length 1 and IIUC the standard also
implicitly says so.

GDB+GCC use a special notation for calls: Address of the call instruction is
used before stepping in, call-instr-length - 1 address is used when inside the
callee and then normally address of next instruction after the call one when
the callee returns.


Regards,
Jan