Re: RFA: handle "MiniDebuginfo" section

["Ulrich Weigand" <uweigand@de.ibm.com>]

Tom Tromey wrote:
> >>>>> "Ulrich" == Ulrich Weigand <uweigand@de.ibm.com> writes:
> Ulrich> Yes, that works for me!  Thanks for the quick fix!
> 
> I'm going to check it in with this ChangeLog:

Thanks!

> Ulrich> FAIL: gdb.base/gnu-debugdata.exp: objcopy 1
> Ulrich> Apparently this happens because:
> Ulrich> objcopy -S --remove-section .gdb_index --remove-section .comment
> Ulrich> --keep-symbols=/home/uweigand/fsf/gdb-head-build/gdb/testsuite/gdb.base/gnu-debugdata.keep_symbols
> Ulrich> /home/uweigand/fsf/gdb-head-build/gdb/testsuite/gdb.base/gnu-debugdata
> Ulrich> /home/uweigand/fsf/gdb-head-build/gdb/testsuite/gdb.base/gnu-debugdata.mini_debuginfo
> 
> Ulrich> returns a non-zero exit code since the original binary has no .gdb_index
> Ulrich> section (probably because the system compiler is old) ...
> 
> My system doesn't make a .gdb_index by default.
> So it must be something else.

Right, it turns out the problem isn't the --remove-section; the problem
rather seems to be that the file passed for --keep-symbols is empty.

This in turn is because of the filter for "T" type symbols:
if {[pipeline "nm" \
         [list [transform nm] "${binfile} --format=posix --defined-only"] \
         [list awk "\\{if(\\\$2==\"T\"||\\\$2==\"t\")print\\ \\\$1\\}"] \
         [list sort "" "" "${binfile}.funcsyms"]]} {

The problem on PowerPC64 is that the main function entry points refer to
function descriptors in the data section, and are thus labeled "D"
instead of "T":
_DYNAMIC d 0000000010010948
_IO_stdin_used R 0000000010000820 0000000000000004
__CTOR_END__ d 0000000010010908
__CTOR_LIST__ d 0000000010010900
__DTOR_END__ D 0000000010010918
__DTOR_LIST__ d 0000000010010910
__FRAME_END__ r 00000000100008f8
__JCR_END__ d 0000000010010920
__JCR_LIST__ d 0000000010010920
__bss_start A 0000000010010be0
__data_start D 0000000010010ac8
__do_global_ctors_aux d 0000000010010b68
__do_global_dtors_aux d 0000000010010b08
__dso_handle R 0000000010000828
__fini_array_end d 00000000100108fc
__fini_array_start d 00000000100108fc
__init_array_end d 00000000100108fc
__init_array_start d 00000000100108fc
__libc_csu_fini D 0000000010010b48 0000000000000010
__libc_csu_init D 0000000010010b58 00000000000000d0
__preinit_array_end d 00000000100108fc
__preinit_array_start d 00000000100108fc
_edata A 0000000010010be0
_end A 0000000010010c50
_fini D 0000000010010af8
_init D 0000000010010ae8
_start D 0000000010010ac8 000000000000003c
call_gmon_start d 0000000010010ad8
completed.6441 b 0000000010010c48 0000000000000001
data_start W 0000000010010ac8
debugdata_function d 0000000010010b28 0000000000000054
dtor_idx.6443 b 0000000010010c40 0000000000000008
frame_dummy d 0000000010010b18
main D 0000000010010b38 000000000000004c


If I change the above filter to also accept "D", the test case goes further.
(It still ends up UNSUPPORTED, since it looks like I don't have LZMA on the
system ...).   I'm not sure why the filter for "T" is done; would it change
something critical to the test if "D" were added?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com