From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2570 invoked by alias); 9 Dec 2007 01:19:48 -0000 Received: (qmail 2560 invoked by uid 22791); 9 Dec 2007 01:19:47 -0000 X-Spam-Check-By: sourceware.org Received: from mu-out-0910.google.com (HELO mu-out-0910.google.com) (209.85.134.185) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 09 Dec 2007 01:19:38 +0000 Received: by mu-out-0910.google.com with SMTP id g7so3432508muf for ; Sat, 08 Dec 2007 17:19:35 -0800 (PST) Received: by 10.82.149.8 with SMTP id w8mr4009352bud.1197163175178; Sat, 08 Dec 2007 17:19:35 -0800 (PST) Received: from ?78.130.98.6? ( [78.130.98.6]) by mx.google.com with ESMTPS id c4sm5137694nfi.2007.12.08.17.19.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 08 Dec 2007 17:19:34 -0800 (PST) Message-ID: <475B4263.2000301@portugalmail.pt> Date: Sun, 09 Dec 2007 02:19:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13pre) Gecko/20071023 Thunderbird/1.5.0.14pre Mnenhy/0.7.5.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: enable seperate debug info testing with stabs References: <472660D1.2040008@portugalmail.pt> In-Reply-To: <472660D1.2040008@portugalmail.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00139.txt.bz2 Pedro Alves wrote: > The problems described in the comment I'm removing seem to > be solved already. I can run the tests successfully on > Cygwin, where stabs is still the default. > Any comments on the patch below? The stabs skipping came originally [1] from gdb.base/sepdebug.exp, to address stabs+ problems reported here [2] and Daniel moved it later to lib/gdb.exp [3]. [1] http://www.sourceware.org/ml/gdb-patches/2004-01/msg00317.html [2] http://www.sourceware.org/ml/gdb-patches/2003-11/msg00275.html [3] http://www.sourceware.org/ml/gdb-patches/2006-10/msg00066.html To give it broader testing, I've tested it on i686-pc-linux-gnu/stabs+ and on i686-pc-cygwin/stabs+ with this board file, based on sepdebug.exp and on a board file Jim posted on the list to use with elfutils. This one's to use with binutils. Its purpose is to run the whole testsuite in "separate debug info" mode. load_base_board_description "unix" #load_base_board_description "cygwin" proc ${current_target_name}_compile {source dest type options} { global strip_to_file_program global EXEEXT # Run the standard compilation procedure. set result [default_target_compile $source $dest $type $options] # If it didn't succeed, return directly. if {[string compare $result ""] != 0} { return $result } if {[string compare $type executable] == 0} { # Note: the procedure gdb_gnu_strip_debug will produce an # executable called ${dest}, which is just like the # executable ($dest) but without the debuginfo. Instead # $dest has a .gnudebuglink section which contains the name # of a debuginfo only file. This file will be stored in the # .debug subdirectory. # Since strip and objdump don't add $EXEEXT automatically like # gcc does, gdb_gnu_strip_debug will fail when $dest doesn't # have $EXEEXT. We workaround that by adding $EXEEXT here if # needed. This is to avoid adding it throughout the # testsuite. set loc_dest $dest set exeext_len [string length $EXEEXT] set dest_len [string length $dest] if { $exeext_len > 0 && $dest_len > $exeext_len } { set suf_pos [expr $dest_len - $exeext_len] set suf [string range $dest $suf_pos $dest_len] if {[string compare $EXEEXT $suf] != 0} { set loc_dest $dest$EXEEXT } } if [gdb_gnu_strip_debug ${loc_dest}] { # check that you have a recent version of strip and # objcopy installed unsupported "cannot produce separate debug info files" return -1 } } return "" } proc ${board}_init { whole_name } { global board_info set baseboard [lindex [split $whole_name "/"] 0] set board_info($baseboard,isremote) 0 } > > ------------------------------------------------------------------------ > > 2007-10-29 Pedro Alves > > * lib/gdb.exp (gdb_gnu_strip_debug): Remove debug format test. > > --- > gdb/testsuite/lib/gdb.exp | 34 ---------------------------------- > 1 file changed, 34 deletions(-) > > Index: src/gdb/testsuite/lib/gdb.exp > =================================================================== > --- src.orig/gdb/testsuite/lib/gdb.exp 2007-10-29 20:15:00.000000000 +0000 > +++ src/gdb/testsuite/lib/gdb.exp 2007-10-29 20:23:32.000000000 +0000 > @@ -2520,40 +2520,6 @@ proc build_id_debug_filename_get { exec > > proc gdb_gnu_strip_debug { dest args } { > > - # First, make sure that we can do this. This is nasty. We need to > - # check for the stabs debug format. To do this we must run gdb on > - # the unstripped executable, list 'main' (as to have a default > - # source file), use get_debug_format (which does 'info source') > - # and then see if the debug info is stabs. If so, we bail out. We > - # cannot do this any other way because get_debug_format finds out > - # the debug format using gdb itself, and in case of stabs we get > - # an error loading the program if it is already stripped. An > - # alternative would be to find out the debug info from the flags > - # passed to dejagnu when the test is run. > - > - gdb_exit > - gdb_start > - gdb_load ${dest} > - gdb_test "list main" "" "" > - get_debug_format > - if { [test_debug_format "stabs"] } then { > - # The separate debug info feature doesn't work well in > - # binutils with stabs. It produces a corrupted debug info > - # only file, and gdb chokes on it. It is almost impossible to > - # capture the failing message out of gdb, because it happens > - # inside gdb_load. At that point any error message is > - # intercepted by dejagnu itself, and, because of the error > - # threshold, any faulty test result is changed into an > - # UNRESOLVED. (see dejagnu/lib/framework.exp) > - unsupported "no separate debug info handling with stabs" > - return -1 > - } elseif { [test_debug_format "unknown"] } then { > - # gdb doesn't know what the debug format is. We are out of luck here. > - unsupported "unknown debugging format" > - return -1 > - } > - gdb_exit > - > set debug_file [separate_debug_filename $dest] > set strip_to_file_program [transform strip] > set objcopy_program [transform objcopy]