Hello community, here is the log from the commit of package gdb checked in at Wed May 31 16:53:58 CEST 2006. -------- --- gdb/gdb.changes 2006-05-22 14:54:41.000000000 +0200 +++ gdb/gdb.changes 2006-05-31 14:42:14.000000000 +0200 @@ -1,0 +2,5 @@ +Wed May 31 14:41:40 CEST 2006 - schwab@suse.de + +- Set long double size to 16 [#180103]. + +------------------------------------------------------------------- New: ---- loader_break.diff ppc-long-double.diff ppc64-elf-get-synthetic-symtab.diff ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ gdb.spec ++++++ --- /var/tmp/diff_new_pack.S82PmU/_old 2006-05-31 16:53:18.000000000 +0200 +++ /var/tmp/diff_new_pack.S82PmU/_new 2006-05-31 16:53:18.000000000 +0200 @@ -21,7 +21,7 @@ Autoreqprov: on PreReq: %{install_info_prereq} Version: 6.4.90.20060522 -Release: 1 +Release: 2 Summary: The GNU Debugger Source: gdb-%{version}.tar.bz2 Patch1: gdb-misc.patch @@ -32,6 +32,9 @@ Patch7: ppc-dwarf2-cfi.patch Patch8: pie-relocate.diff Patch9: mst-solib-trampoline.diff +Patch10: ppc64-elf-get-synthetic-symtab.diff +Patch11: loader_break.diff +Patch12: ppc-long-double.diff BuildRoot: %{_tmppath}/%{name}-%{version}-build %description @@ -68,6 +71,11 @@ %patch7 %patch8 %patch9 +%patch10 +cd gdb +%patch11 +cd .. +%patch12 %build CFLAGS="$RPM_OPT_FLAGS" \ @@ -123,6 +131,8 @@ %endif %changelog -n gdb +* Wed May 31 2006 - schwab@suse.de +- Set long double size to 16 [#180103]. * Mon May 22 2006 - schwab@suse.de - Update to gdb 6.4.90 snapshot 20060522. * Sun Apr 23 2006 - schwab@suse.de ++++++ loader_break.diff ++++++ 2006-05-25 Paul Gilliam <pgilliam@us.ibm.com * solib-svr4.c: Remove "._dl_debug_state" from the list of symbols at which to try setting a breakpoint for tracking solibs. (enable_break): Resolve break address when the symbol is found in the data section. Index: solib-svr4.c =================================================================== RCS file: /cvs/src/src/gdb/solib-svr4.c,v retrieving revision 1.58 diff -a -u -r1.58 solib-svr4.c --- solib-svr4.c 18 May 2006 20:38:56 -0000 1.58 +++ solib-svr4.c 25 May 2006 22:12:55 -0000 @@ -85,16 +85,6 @@ "rtld_db_dlactivity", "_rtld_debug_state", - /* On the 64-bit PowerPC, the linker symbol with the same name as - the C function points to a function descriptor, not to the entry - point. The linker symbol whose name is the C function name - prefixed with a '.' points to the function's entry point. So - when we look through this table, we ignore symbols that point - into the data section (thus skipping the descriptor's symbol), - and eventually try this one, giving us the real entry point - address. */ - "._dl_debug_state", - NULL }; @@ -1043,20 +1033,45 @@ /* Now try to set a breakpoint in the dynamic linker. */ for (bkpt_namep = solib_break_names; *bkpt_namep != NULL; bkpt_namep++) { - /* On ABI's that use function descriptors, there are usually - two linker symbols associated with each C function: one - pointing at the actual entry point of the machine code, - and one pointing at the function's descriptor. The - latter symbol has the same name as the C function. - - What we're looking for here is the machine code entry - point, so we are only interested in symbols in code - sections. */ + /* What we're looking for here is the machine code entry point, + so we are only interested in symbols in code sections. + + On ABI's that use function descriptors, the linker symbol with + the same name as a C funtion points to that functions descriptor. + when those function descriptors are in the code section, they + contain executable code and we can set a breakpoint there. */ sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_CODE); if (sym_addr != 0) break; } + if (sym_addr == 0) + { + CORE_ADDR sect_offset; + + /* No symbol was found in a code section, so look in the data + sections. This will only happen when the linker symbol points + to a function descriptor that is in a data section. */ + for (bkpt_namep = solib_break_names; *bkpt_namep!=NULL; bkpt_namep++) + { + /* On ABI's that use function descriptors that are in the data + section, */ + sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_DATA); + if (sym_addr != 0) + break; + } + if (sym_addr == 0) + { + target_close (tmp_bfd_target, 0); + goto bkpt_at_symbol; + } + + /* Convert 'sym_addr' from a function pointer to an address. */ + sym_addr = gdbarch_convert_from_func_ptr_addr (current_gdbarch, + sym_addr, + tmp_bfd_target); + } + /* We're done with both the temporary bfd and target. Remember, closing the target closes the underlying bfd. */ target_close (tmp_bfd_target, 0); ++++++ ppc-long-double.diff ++++++ --- gdb/ppc-linux-tdep.c +++ gdb/ppc-linux-tdep.c @@ -1065,6 +1065,7 @@ { struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); +#if 0 /* NOTE: jimb/2004-03-26: The System V ABI PowerPC Processor Supplement says that long doubles are sixteen bytes long. However, as one of the known warts of its ABI, PPC GNU/Linux uses @@ -1074,6 +1075,7 @@ double' on PPC GNU/Linux are non-conformant. */ /* NOTE: cagney/2005-01-25: True for both 32- and 64-bit. */ set_gdbarch_long_double_bit (gdbarch, 8 * TARGET_CHAR_BIT); +#endif if (tdep->wordsize == 4) { ++++++ ppc64-elf-get-synthetic-symtab.diff ++++++

From nobody Tue May 23 14:02:48 2006 From: Alan Modra <amodra@bigpond.net.au> Subject: PowerPC64 synthetic syms To: binutils@sourceware.org Date: Tue, 23 May 2006 11:02:14 +0930 Mail-Followup-To: binutils@sourceware.org

PowerPC64 bfd_get_synthetic_symtab provides pseudo function entry symbols (dot-symbols) for object files generated by newer toolchains. This is useful for objdump disassembly of object files. gdb also has at least one place where a dot-symbol is searched, solib-svr4.c solib_break_names, so relies on bfd_get_synthetic_symtab. A recent testcase shows this to be unreliable because the ppc64 back-end only creates one synthetic sym for each function descriptor, and ld.so happens to have *two* symbols pointing at the functions descriptor. Which dot-symbol is created depends on symbol table hash order. Really, gdb should be looking up the function descriptor syms itself instead of relying on a crutch like the synthetic syms, but the following patch happens to cure gdb and makes sense in isolation. Applying mainline and 2.17. * elf64-ppc.c (compare_symbols): Prefer strong dynamic global function syms over other syms. Index: bfd/elf64-ppc.c =================================================================== RCS file: /cvs/src/src/bfd/elf64-ppc.c,v retrieving revision 1.238 diff -u -p -r1.238 elf64-ppc.c --- bfd/elf64-ppc.c 9 May 2006 03:38:30 -0000 1.238 +++ bfd/elf64-ppc.c 23 May 2006 01:29:40 -0000 @@ -2626,6 +2626,32 @@ compare_symbols (const void *ap, const v if (a->value + a->section->vma > b->value + b->section->vma) return 1; + /* For syms with the same value, prefer strong dynamic global function + syms over other syms. */ + if ((a->flags & BSF_GLOBAL) != 0 && (b->flags & BSF_GLOBAL) == 0) + return -1; + + if ((a->flags & BSF_GLOBAL) == 0 && (b->flags & BSF_GLOBAL) != 0) + return 1; + + if ((a->flags & BSF_FUNCTION) != 0 && (b->flags & BSF_FUNCTION) == 0) + return -1; + + if ((a->flags & BSF_FUNCTION) == 0 && (b->flags & BSF_FUNCTION) != 0) + return 1; + + if ((a->flags & BSF_WEAK) == 0 && (b->flags & BSF_WEAK) != 0) + return -1; + + if ((a->flags & BSF_WEAK) != 0 && (b->flags & BSF_WEAK) == 0) + return 1; + + if ((a->flags & BSF_DYNAMIC) != 0 && (b->flags & BSF_DYNAMIC) == 0) + return -1; + + if ((a->flags & BSF_DYNAMIC) == 0 && (b->flags & BSF_DYNAMIC) != 0) + return 1; + return 0; } -- Alan Modra IBM OzLabs - Linux Technology Centre ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Remember to have fun...