From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27496 invoked by alias); 7 Aug 2003 08:49:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27489 invoked from network); 7 Aug 2003 08:49:27 -0000 Received: from unknown (HELO maxipes.logix.cz) (81.0.234.97) by sources.redhat.com with SMTP; 7 Aug 2003 08:49:27 -0000 Received: from suse.cz (styx.suse.cz [213.210.157.162]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Michal Ludvig", Issuer "Personal Freemail RSA 2000.8.30" (verified OK)) by maxipes.logix.cz (Postfix) with ESMTP id D712F299BE for ; Thu, 7 Aug 2003 10:49:26 +0200 (CEST) Message-ID: <3F3212B7.8060003@suse.cz> Date: Thu, 07 Aug 2003 08:49:00 -0000 From: Michal Ludvig Organization: SuSE CR, s.r.o. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.5a) Gecko/20030718 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: gdb Subject: [testsuite & dwarf2] How to handle store.exp failure on AMD64? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-08/txt/msg00088.txt.bz2 Hi all, on AMD64 I'm getting these failures: Running /ttt/64/gdb-head/gdb/testsuite/gdb.base/store.exp ... FAIL: gdb.base/store.exp: up print old r - charest FAIL: gdb.base/store.exp: up print old r - short FAIL: gdb.base/store.exp: up print old r - int FAIL: gdb.base/store.exp: up print old r - long FAIL: gdb.base/store.exp: up print old r - longest FAIL: gdb.base/store.exp: up print old r - float FAIL: gdb.base/store.exp: up print old r - double Maybe these failures should be turned into "expected failures" or something alike [see below for other solutions]. Why? This is an extracted testcase: ============= int add_int (register int u, register int v) { return u + v; } int wack_int (register int u, register int v) { register int l = u, r = v; l = add_int (l, r); return l + r; } int main (void) { return wack_int (-1, -2); } ============= Compile it and do the steps that store.exp does: $ ./gdb store GNU gdb 5.3.90_2003-08-07-cvs [...] This GDB was configured as "x86_64-unknown-linux-gnu"... (gdb) break add_int Breakpoint 1 at 0x40040c: file store.c, line 6. (gdb) run Starting program: /ttt/64/tst/store Breakpoint 1, add_int (u=-1, v=-2) at store.c:6 6 return u + v; (gdb) up #1 0x0000000000400429 in wack_int (u=-1, v=-2) at store.c:13 13 l = add_int (l, r); (gdb) print r $1 = (gdb) The testsuite expects that 'r' will have a value '-2' which is not the case here. The problem is, that 'r' lives in the register (%rbx) but .debug_frame doesn't contain information how to unwind it's previous value. When I manually added the appropriate rule (DW_CFA_same_value[rbx]) to the generated asm file store.s it worked, but GCC obviously doesn't put it there. The testsuite also works if I undefine the 'register' keyword. Then the variables live in the memory and everything is fine. What's the purpose of having the 'register' keyword in this testcase? When the code isn't optimized it doesn't matter where the value lives and if you optimize it then GCC itself decides if it should go to the register or not. So I see these possible solutions for inhibiting AMD64 testcase failures: 1) undefine 'register' keyword when running the testsuite on AMD64, or 2) make these failures expected on AMD64, or 3) convince GCC to put 'DW_CFA_same_value' for all non-destroyed registers, or 4) let GDB pretend that all registers have the same value unless said otherwise later in the .debug_frame and convince GCC to put a note when their value is overwritten. Opinions? Michal Ludvig -- * SuSE CR, s.r.o * mludvig@suse.cz * (+420) 296.545.373 * http://www.suse.cz