From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21200 invoked by alias); 19 Nov 2002 11:38:09 -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 21189 invoked from network); 19 Nov 2002 11:38:05 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 19 Nov 2002 11:38:05 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id gAJBLTL22384; Tue, 19 Nov 2002 06:21:29 -0500 To: Alexander Larsson Cc: gdb@sources.redhat.com Subject: Re: Final separate debug info patch References: From: Jim Blandy Date: Tue, 19 Nov 2002 03:38:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-11/txt/msg00213.txt.bz2 Alexander Larsson writes: > On 19 Nov 2002, Jim Blandy wrote: > > > > > It looks like the stripping process may break some executables. If $D > > is the top directory of a current GDB source tree, try this: > > > > $ g++ --version > > g++ (GCC) 3.3 20020820 (experimental) > > Copyright (C) 2002 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > > $ g++ -g $D/gdb/testsuite/gdb.c++/try_catch.cc -o try_catch > > $ ./try_catch > > $ /home/jimb/elfutils/bin/strip -f try_catch.separate-debug try_catch > > $ ./try_catch > > Segmentation fault > > $ > > This doesn't happen for me with gdb from cvs HEAD and gcc (GCC) 3.2 > 20020903 (Red Hat Linux 8.0 3.2-7). Does it happen if you just run strip > without the -f flag? It might well be a bug in the new strip > command. Yeah, it seems to be: zenia:separate-debug$ g++ -g $D/gdb/testsuite/gdb.c++/try_catch.cc -o try_catch zenia:separate-debug$ ./try_catch zenia:separate-debug$ /home/jimb/elfutils/bin/strip try_catch zenia:separate-debug$ ./try_catch Segmentation fault zenia:separate-debug$ This is happening with a pretty motley collection of utilities, so I'm not sure I can show how to reproduce it. If you could try running the GDB test suite on your box with the stuff I've provided, that would be nice. Here's the latest iteration of my unix-separate-debug.exp file: --- load_base_board_description "unix" set strip_to_file_program "/home/jimb/elfutils/bin/strip" proc ${current_target_name}_compile {source dest type options} { global strip_to_file_program # 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 } # Otherwise, strip the executable and copy its debug info to a # separate file, leaving only a pointer behind. if {[string compare $type executable] == 0} { exec $strip_to_file_program -f ${dest}.separate-debug ${dest} } } # "unix" is a magic target name to is_remote, so since we're not named # "unix", we have to spell some stuff out. # We can't just call set_board_info here, since # 1) that doesn't strip off variant information, and # 2) it won't override the default guess established by setup_target_hook. set board_info([lindex [split $board "/"] 0],isremote) 0 --- See if you can get that working. There is a regression in reread.exp, and you can ignore everything in schedlock.exp. But you may find something that tweaks the problem on your system. My stripped program seems to be crashing in _dl_map_object_deps...