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

[Michael Haupt <michael.haupt@oracle.com>]

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--