Re: Final separate debug info patch

[Jim Blandy <jimb@redhat.com>]

Alexander Larsson <alexl@redhat.com> 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...