From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12105 invoked by alias); 21 Mar 2013 20:15:38 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 11815 invoked by uid 89); 21 Mar 2013 20:15:30 -0000 X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MIME_QP_LONG_LINE,RP_MATCHES_RCVD autolearn=ham version=3.3.1 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 21 Mar 2013 20:15:27 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2LKFO6K028120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 21 Mar 2013 20:15:25 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2LKFO12008171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Mar 2013 20:15:24 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2LKFOQY029969 for ; Thu, 21 Mar 2013 15:15:24 -0500 Received: from [192.168.2.100] (/84.191.49.138) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Mar 2013 13:15:24 -0700 Subject: Re: "optimized out" in spite of DWARF saying otherwise? References: <20130321164806.GA19532@host2.jankratochvil.net> From: Michael Haupt Content-Type: text/plain; charset=us-ascii In-Reply-To: <20130321164806.GA19532@host2.jankratochvil.net> Message-Id: <89D4A69A-008A-4D56-9F2C-1F94AE41F62D@oracle.com> Date: Thu, 21 Mar 2013 20:15:00 -0000 To: gdb@sourceware.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-SW-Source: 2013-03/txt/msg00066.txt.bz2 Jan, Am 21.03.2013 um 17:48 schrieb 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 >>=20 >> 0x...e642 - 0x...e642: rdi >>=20 >> (note start and end are the same). gdb, however, insists on the value be= ing >> "", with the current address being 0x...e642. How is this? >=20 > That is correct. DWARF4: > 2. An ending address offset. [...] It marks the first address past the en= d of > the address range over which the location is valid. >=20 > 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: 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: List-Subscribe: List-Archive: List-Post: List-Help: , 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 To: Joel Sherrill 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" 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: >=20 > + 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 >=20 > Attached is a tarball from git which has a patch per simulator directory > touched. The last patch is the regeneration of configure's. >=20 > 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]" =3D "always"; then > + AC_MSG_ERROR([Sorry, but this simulator requires that hardware suppo= rt=20 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 b= e=20 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 should be two spaces between your name & e-mail. you should check all the= =20 ChangeLog entries accordingly. > + * configure.ac: Use $SIM_DV_SOCKSER_O should have a period at the end. you should check all the ChangeLog entrie= s=20 accordingly. > 0003-sim-mips-Address-use-of-dv-sockser.o.patch > > + AC_MSG_ERROR([Sorry, but tx3904sio hardware support is unavailable=20 for your target. Please use --disable-sim-hardware, or pass a list of devi= ces=20 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= =20 patches have that, so you should grep for tabs to make sure none are left i= n. > 0005-frv-configure.ac-Address-use-of-dv-sockser.o.patch > > + AC_MSG_ERROR([Sorry, but hardware support in this simulator=20 unconditionally relies on dv-sockser.o, it is unavailable for your host.=20 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--