Shared library call problems on PowerPC with current binutils/gdb

Shared library call problems on PowerPC with current binutils/gdb

[Ulrich Weigand]

Hello,

using current binutils and gdb head on powerpc-linux, you see the
following quite annoying effect(s) with shared library calls.

I'm starting out with a simple "hello world" program (compiled with
-ffreestanding to avoid the compiler optimizing the printf to puts),
and the following debugging session:

>GNU gdb 6.8.50.20080408
>Copyright (C) 2008 Free Software Foundation, Inc.
>License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>This is free software: you are free to change and redistribute it.
>There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>and "show warranty" for details.
>This GDB was configured as "powerpc64-linux"...
>(gdb) break printf
>Function "printf" not defined.
>Make breakpoint pending on future shared library load? (y or [n]) n

Hmmm.  Ok, maybe because libc is not loaded yet ...

>(gdb) start
>Breakpoint 1 at 0x10000474: file hello.c, line 6.
>Starting program: /home/uweigand/a.out
>main () at hello.c:6
>6         printf ("Hello, world!\n");
>(gdb) info sharedlibrary
From        To          Syms Read   Shared Object Library
>0x0ffc1960  0x0ffda700  Yes         /lib/ld.so.1
>0x0fe3db20  0x0ff5e230  Yes         /lib/libc.so.6
>(gdb) break printf
>Function "printf" not defined.
>Make breakpoint pending on future shared library load? (y or [n]) n

Well, libc is definitely loaded now, but I still cannot set a
breakpoint ...   Maybe stepping in works?

>(gdb) s
>0x10000800 in call___do_global_ctors_aux ()

Not really.

>(gdb) start
>The program being debugged has been started already.
>Start it from the beginning? (y or n) y
>Breakpoint 2 at 0x10000474: file hello.c, line 6.
>Starting program: /home/uweigand/a.out
>main () at hello.c:6
>6         printf ("Hello, world!\n");
>(gdb) n
>0x10000800 in call___do_global_ctors_aux ()

Huh.  Not even stepping over works ...

>(gdb) bt
>#0  0x10000800 in call___do_global_ctors_aux ()
>#1  0x0fe3de0c in generic_start_main () from /lib/libc.so.6
>#2  0x0fe3e060 in __libc_start_main () from /lib/libc.so.6
>#3  0x00000000 in ?? ()

... and I guess that's the reason why.

>(gdb) n
>Single stepping until exit from function call___do_global_ctors_aux,
>which has no line number information.
>0x0ffd544c in _dl_runtime_resolve () from /lib/ld.so.1
>(gdb)
>Single stepping until exit from function _dl_runtime_resolve,
>which has no line number information.
>0x0fe75820 in printf@@GLIBC_2.4 () from /lib/libc.so.6
>(gdb)
>Single stepping until exit from function printf@@GLIBC_2.4,
>which has no line number information.
>Hello, world!
>main () at hello.c:7
>7       }

Also, it's quite tedious to get back.



So, what's going on here?  It looks like a combination of multiple
different problems.

1) Setting a breakpoint on a shared library function (that is called by
   the main program) before libraries are loaded used to work because
   of the so-called "solib trampoline" minimal symbols.

   These are generated by GDB when it finds an *undefined* symbol in
   the dynamic symbol table with a *non-zero* value.  Those are a special
   "hack" used by the linker to implement function pointer comparison
   correctly; their "value" points to the PLT call stub in the main
   executable used to call the shared library function.

   However, over time BFD has been optimized to only use this hack when
   it is actually necessary, i.e. when the symbol is in fact used for
   purposed of function pointer comparisons.  In simple cases like this
   where the function is just called, the value of the undefined symbol
   is now always 0 when using current binutils.

   On the other hand, BFD now provides "synthetic symbols" that point to
   those same PLT call stubs (on many targets).  In fact, the synthetic
   symbol "printf@plt" is actually defined.  However, elfread.c does not
   consider this to be a "solib trampoline" symbol for printf.

   Even if it would, there is an additional complication on PowerPC: 
   when using the new-style "secure" PLTs, the "printf@plt" entry point
   actually points to a *data* variable holding a pointer to the "glink"
   stub, not the original PLT call stub itself.

   This could still work, as ppc-linux-tdep.c actually contains code to
   treat this as a case of "function descriptors" and would resolve to
   the real target.  However, "break printf" actually still wouldn't work
   because linespec.c:minsym_found does not handle function descriptors ...

2) What about when libc is already loaded?  Why is printf still not found?
   This is because the (static) symbol table of libc.so on current powerpc
   systems does not contain a symbol "printf", only "printf@@GLIBC_2.4" and
   "printf@GLIBC_2.0".  This is because of symbol versioning needed to handle
   both 128-bit and 64-bit long double types.

   Now, the *dynamic* table *does* contain "printf" (twice, with different
   version information), but elfread.c ignores the dynamic table "as the
   dynamic symbol table is usually a subset of the main symbol table."

   Note that even if full debug information for libc.so is available, we
   do not get a debug symbol "printf" either -- the two entry points are
   called __printf and __nldbl_printf in the original source, and that's
   what debug symbols show.

3) As to stepping in and/or over the printf call, the primary reason why
   this doesn't work is that unwinding breaks.  The immediate target of 
   the call instruction is a PLT call stub; these stubs are part of the
   .text section (when using the secure PLT scheme) and have no symbols.

   The immediately preceding symbol happens to be call___do_global_ctors_aux
   from GCC's crtend.o, which is compiled with -finhibit-size-directive,
   so that function is considered by GDB to span until the end of .text.

   Thus prolog parsing of call___do_global_ctors_aux detects building of
   a stack frame, and GDB assumes that the PLT call stubs have one -- 
   which they really don't.

4) Even if that worked, stepping *into* the call would require support
   for gdbarch_skip_trampoline_code, and the current ppc32 implementation
   of that (for secure PLTs) simply calls find_solib_trampoline_target
   -- which requires the old-style "solib trampoline" symbols to work.



To fix this, I'd propose the following implementation steps:

- Extend elf_symtab_read to treat a synthetic symbol XXX@plt as a
  mst_solib_trampoline symbol for XXX.

- Change elf_symtab_read to register symbols with version name
  simply under their base name.

- Include something along the lines of Markus' "multiply-defined
  symbol" patch so that "break printf" will break on *both* definitions
  (created by the two symbols with different version names) after libc
  has been loaded.

- Teach minsym_found about function descriptors.

- Add extra unwinders to ppc-linux-tdep that recognize the various
  PLT call and glink stubs, and properly treat them as frameless.
  (This will probably require code reading ...)

- Extend ppc_skip_trampoline_code to likewise handle those stubs.


Does this look reasonable?  Am I overlooking anything?

Bye,
Ulrich

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

Re: Shared library call problems on PowerPC with current binutils/gdb

[Daniel Jacobowitz]

On Tue, Apr 29, 2008 at 12:53:58AM +0200, Ulrich Weigand wrote:
> - Extend elf_symtab_read to treat a synthetic symbol XXX@plt as a
>   mst_solib_trampoline symbol for XXX.

Sounds reasonable.  I suggested this to Aleksandar for another
problem, even :-) Though it was kind of nice to have it show up in
disassembly with @plt; will it still do that?  It's nice to know
immediately when I'm looking at the PLT stub instead of the
definition.

> - Change elf_symtab_read to register symbols with version name
>   simply under their base name.
> 
> - Include something along the lines of Markus' "multiply-defined
>   symbol" patch so that "break printf" will break on *both* definitions
>   (created by the two symbols with different version names) after libc
>   has been loaded.
> 
> - Teach minsym_found about function descriptors.

These sound like a good idea to me.

> - Add extra unwinders to ppc-linux-tdep that recognize the various
>   PLT call and glink stubs, and properly treat them as frameless.
>   (This will probably require code reading ...)
> 
> - Extend ppc_skip_trampoline_code to likewise handle those stubs.

These too, but it would be nice if we could avoid code reading all
the time.  Maybe only do it for symbols without a name or where
the defining symbol has size zero?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Shared library call problems on PowerPC with current binutils/gdb

[Daniel Jacobowitz]

On Mon, Apr 28, 2008 at 08:39:51PM -0400, Daniel Jacobowitz wrote:
> On Tue, Apr 29, 2008 at 12:53:58AM +0200, Ulrich Weigand wrote:
> > - Extend elf_symtab_read to treat a synthetic symbol XXX@plt as a
> >   mst_solib_trampoline symbol for XXX.
> 
> Sounds reasonable.  I suggested this to Aleksandar for another
> problem, even :-) Though it was kind of nice to have it show up in
> disassembly with @plt; will it still do that?  It's nice to know
> immediately when I'm looking at the PLT stub instead of the
> definition.

Relatedly, could we change find_solib_trampoline_target instead, to
allow "@plt"?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Shared library call problems on PowerPC with current binutils/gdb

[Daniel Jacobowitz]

On Mon, Apr 28, 2008 at 08:39:51PM -0400, Daniel Jacobowitz wrote:
> On Tue, Apr 29, 2008 at 12:53:58AM +0200, Ulrich Weigand wrote:
> > - Extend elf_symtab_read to treat a synthetic symbol XXX@plt as a
> >   mst_solib_trampoline symbol for XXX.
> 
> Sounds reasonable.  I suggested this to Aleksandar for another
> problem, even :-) Though it was kind of nice to have it show up in
> disassembly with @plt; will it still do that?  It's nice to know
> immediately when I'm looking at the PLT stub instead of the
> definition.

This appears to work consistently, where by work I mean disassembly
shows the @plt sym but breakpoints on the undecorated version work
fine.  I'm not sure exactly why; it may be luck.  If it's luck
and someone cares later, we could make it work reliably by making
sure the @plt version has an accurate size and the non-@plt version
has size 0, or by making lookup_minimal_symbol_by_pc_section
explicitly prefer text to non-text symbols.

Hmm, thinking about this more, it probably won't work for your
case after all.  lookup_solib_trampoline_symbol_by_pc will return
NULL if the first symbol we find is the text version.

What do you think?  I wrote this because I need it to get some symbol
for malloc on Symbian, where I do not have a symbol file corresponding
to libc.  The PLT entry works nicely for that purpose.

-- 
Daniel Jacobowitz
CodeSourcery

2008-05-02  Daniel Jacobowitz  <dan@codesourcery.com>

	* elfread.c (elf_symtab_read): Create trampolines for @plt symbols.

Index: symbian-fsf/gdb/elfread.c
===================================================================
--- symbian-fsf.orig/gdb/elfread.c	2008-05-02 16:56:20.000000000 -0400
+++ symbian-fsf/gdb/elfread.c	2008-05-02 17:34:42.000000000 -0400
@@ -521,6 +521,33 @@ elf_symtab_read (struct objfile *objfile
 	  if (msym != NULL)
 	    msym->filename = filesymname;
 	  gdbarch_elf_make_msymbol_special (gdbarch, sym, msym);
+
+	  /* For @plt symbols, also record a trampoline to the
+	     destination symbol.  The @plt symbol will be used in
+	     disassembly, and the trampoline will be used when we are
+	     trying to find the target.  */
+	  if (msym && ms_type == mst_text && type == ST_SYNTHETIC)
+	    {
+	      int len = strlen (sym->name);
+
+	      if (len > 4 && strcmp (sym->name + len - 4, "@plt") == 0)
+		{
+		  char *base_name = alloca (len - 4 + 1);
+		  struct minimal_symbol *mtramp;
+
+		  memcpy (base_name, sym->name, len - 4);
+		  base_name[len - 4] = '\0';
+		  mtramp = record_minimal_symbol (base_name, symaddr,
+						  mst_solib_trampoline,
+						  sym->section, objfile);
+		  if (mtramp)
+		    {
+		      MSYMBOL_SIZE (mtramp) = MSYMBOL_SIZE (msym);
+		      mtramp->filename = filesymname;
+		      gdbarch_elf_make_msymbol_special (gdbarch, sym, mtramp);
+		    }
+		}
+	    }
 	}
     }
 }

Re: Shared library call problems on PowerPC with current binutils/gdb

[Ulrich Weigand]

Daniel Jacobowitz wrote:

> This appears to work consistently, where by work I mean disassembly
> shows the @plt sym but breakpoints on the undecorated version work
> fine.  I'm not sure exactly why; it may be luck.  If it's luck
> and someone cares later, we could make it work reliably by making
> sure the @plt version has an accurate size and the non-@plt version
> has size 0, or by making lookup_minimal_symbol_by_pc_section
> explicitly prefer text to non-text symbols.
> 
> Hmm, thinking about this more, it probably won't work for your
> case after all.  lookup_solib_trampoline_symbol_by_pc will return
> NULL if the first symbol we find is the text version.

If we have two symbols, *both* need to be mst_solib_trampoline.

As an alternative to having two symbols, I'm wondering if there is a
way to have just one symbol with differing SYMBOL_PRINT_NAME (with
@plt) and SYMBOL_SEARCH_NAME (without @plt).  The same might also be
nice for versioned symbols.

I've also been thinking about the same approach to show PowerPC64
'dot' symbols without the dot when printing them ...

Bye,
Ulrich

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

Re: Shared library call problems on PowerPC with current binutils/gdb

[Daniel Jacobowitz]

On Sat, May 03, 2008 at 12:29:04AM +0200, Ulrich Weigand wrote:
> Daniel Jacobowitz wrote:
> 
> > This appears to work consistently, where by work I mean disassembly
> > shows the @plt sym but breakpoints on the undecorated version work
> > fine.  I'm not sure exactly why; it may be luck.

lookup_minimal_symbol_by_pc_section takes the last match in case of
multiple matches.  Minimal symbols are sorted by name.  So malloc@plt
always sorts after malloc.  Subtle, but not luck exactly.

> > Hmm, thinking about this more, it probably won't work for your
> > case after all.  lookup_solib_trampoline_symbol_by_pc will return
> > NULL if the first symbol we find is the text version.
> 
> If we have two symbols, *both* need to be mst_solib_trampoline.

Would that be true if we could search for a symbol with the
appropriate type?  Prefer the trampoline when trying to find a
trampoline target, prefer the text symbol with the decorated name
otherwise.

Giving them different names could work too, but there are so
many different "symbol names" that giving them further distinction
makes me nervous (NATURAL, LINKAGE, DEMANGLED, PRINT, SEARCH).

-- 
Daniel Jacobowitz
CodeSourcery

Re: Shared library call problems on PowerPC with current binutils/gdb

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> On Sat, May 03, 2008 at 12:29:04AM +0200, Ulrich Weigand wrote:
> > Daniel Jacobowitz wrote:
> > 
> > > This appears to work consistently, where by work I mean disassembly
> > > shows the @plt sym but breakpoints on the undecorated version work
> > > fine.  I'm not sure exactly why; it may be luck.
> 
> lookup_minimal_symbol_by_pc_section takes the last match in case of
> multiple matches.  Minimal symbols are sorted by name.  So malloc@plt
> always sorts after malloc.  Subtle, but not luck exactly.

I see.  Hmmm, we could do the same for versioned symbols and just
install two minsyms.  For disassembly, we'd see the decorated name,
but searching for just the base name would find the function as well ...

> > > Hmm, thinking about this more, it probably won't work for your
> > > case after all.  lookup_solib_trampoline_symbol_by_pc will return
> > > NULL if the first symbol we find is the text version.
> > 
> > If we have two symbols, *both* need to be mst_solib_trampoline.
> 
> Would that be true if we could search for a symbol with the
> appropriate type?  Prefer the trampoline when trying to find a
> trampoline target, prefer the text symbol with the decorated name
> otherwise.

That's probably the best solution, right.

Bye,
Ulrich

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

Re: Shared library call problems on PowerPC with current binutils/gdb

[Daniel Jacobowitz]

On Sat, May 03, 2008 at 05:38:40PM +0200, Ulrich Weigand wrote:
> I see.  Hmmm, we could do the same for versioned symbols and just
> install two minsyms.  For disassembly, we'd see the decorated name,
> but searching for just the base name would find the function as well ...

There's a downside of this; it shows up twice in info functions,
rbreak, et cetera.

(gdb) rbreak malloc
Breakpoint 3 at 0x97f8
<function, no debug info> malloc;
Note: breakpoint 3 also set at pc 0x97f8.
Breakpoint 4 at 0x97f8
<function, no debug info> malloc@plt;

So it may be worth pursuing the two-names approach, or fixing up
things that list symbols to omit multiple symbols at the same address.
That latter could be useful anyway for glibc aliases.  I'm not sure.

> > > > Hmm, thinking about this more, it probably won't work for your
> > > > case after all.  lookup_solib_trampoline_symbol_by_pc will return
> > > > NULL if the first symbol we find is the text version.
> > > 
> > > If we have two symbols, *both* need to be mst_solib_trampoline.
> > 
> > Would that be true if we could search for a symbol with the
> > appropriate type?  Prefer the trampoline when trying to find a
> > trampoline target, prefer the text symbol with the decorated name
> > otherwise.
> 
> That's probably the best solution, right.

Here's the patch I'm currently using.

-- 
Daniel Jacobowitz
CodeSourcery

2008-05-03  Daniel Jacobowitz  <dan@codesourcery.com>

	* elfread.c (elf_symtab_read): Create trampolines for @plt symbols.
	* minsyms.c (lookup_minimal_symbol_by_pc_section_1): Renamed from
	lookup_minimal_symbol_by_pc_section.  Prefer trampolines if requested.
	(lookup_minimal_symbol_by_pc_section): Use
	lookup_minimal_symbol_by_pc_section_1.
	(lookup_solib_trampoline_symbol_by_pc): Likewise.

--- gdb/elfread.c	(revision 1034)
+++ gdb/elfread.c	(local)
@@ -521,6 +521,33 @@ elf_symtab_read (struct objfile *objfile
 	  if (msym != NULL)
 	    msym->filename = filesymname;
 	  gdbarch_elf_make_msymbol_special (gdbarch, sym, msym);
+
+	  /* For @plt symbols, also record a trampoline to the
+	     destination symbol.  The @plt symbol will be used in
+	     disassembly, and the trampoline will be used when we are
+	     trying to find the target.  */
+	  if (msym && ms_type == mst_text && type == ST_SYNTHETIC)
+	    {
+	      int len = strlen (sym->name);
+
+	      if (len > 4 && strcmp (sym->name + len - 4, "@plt") == 0)
+		{
+		  char *base_name = alloca (len - 4 + 1);
+		  struct minimal_symbol *mtramp;
+
+		  memcpy (base_name, sym->name, len - 4);
+		  base_name[len - 4] = '\0';
+		  mtramp = record_minimal_symbol (base_name, symaddr,
+						  mst_solib_trampoline,
+						  sym->section, objfile);
+		  if (mtramp)
+		    {
+		      MSYMBOL_SIZE (mtramp) = MSYMBOL_SIZE (msym);
+		      mtramp->filename = filesymname;
+		      gdbarch_elf_make_msymbol_special (gdbarch, sym, mtramp);
+		    }
+		}
+	    }
 	}
     }
 }
--- gdb/minsyms.c	(revision 1034)
+++ gdb/minsyms.c	(local)
@@ -357,10 +357,15 @@ lookup_minimal_symbol_solib_trampoline (
    ALL the minimal symbol tables before deciding on the symbol that
    comes closest to the specified PC.  This is because objfiles can
    overlap, for example objfile A has .text at 0x100 and .data at
-   0x40000 and objfile B has .text at 0x234 and .data at 0x40048.  */
+   0x40000 and objfile B has .text at 0x234 and .data at 0x40048.
 
-struct minimal_symbol *
-lookup_minimal_symbol_by_pc_section (CORE_ADDR pc, asection *section)
+   If WANT_TRAMPOLINE is set, prefer mst_solib_trampoline symbols when
+   there are text and trampoline symbols at the same address.
+   Otherwise prefer mst_text symbols.  */
+
+static struct minimal_symbol *
+lookup_minimal_symbol_by_pc_section_1 (CORE_ADDR pc, asection *section,
+				       int want_trampoline)
 {
   int lo;
   int hi;
@@ -369,7 +374,11 @@ lookup_minimal_symbol_by_pc_section (COR
   struct minimal_symbol *msymbol;
   struct minimal_symbol *best_symbol = NULL;
   struct obj_section *pc_section;
+  enum minimal_symbol_type want_type, other_type;
 
+  want_type = want_trampoline ? mst_solib_trampoline : mst_text;
+  other_type = want_trampoline ? mst_text : mst_solib_trampoline;
+  
   /* PC has to be in a known section.  This ensures that anything
      beyond the end of the last segment doesn't appear to be part of
      the last function in the last segment.  */
@@ -486,6 +495,24 @@ lookup_minimal_symbol_by_pc_section (COR
 		      continue;
 		    }
 
+		  /* If we are looking for a trampoline and this is a
+		     text symbol, or the other way around, check the
+		     preceeding symbol too.  If they are otherwise
+		     identical prefer that one.  */
+		  if (hi > 0
+		      && MSYMBOL_TYPE (&msymbol[hi]) == other_type
+		      && MSYMBOL_TYPE (&msymbol[hi - 1]) == want_type
+		      && (MSYMBOL_SIZE (&msymbol[hi])
+			  == MSYMBOL_SIZE (&msymbol[hi - 1]))
+		      && (SYMBOL_VALUE_ADDRESS (&msymbol[hi])
+			  == SYMBOL_VALUE_ADDRESS (&msymbol[hi - 1]))
+		      && (SYMBOL_BFD_SECTION (&msymbol[hi])
+			  == SYMBOL_BFD_SECTION (&msymbol[hi - 1])))
+		    {
+		      hi--;
+		      continue;
+		    }
+
 		  /* If the minimal symbol has a zero size, save it
 		     but keep scanning backwards looking for one with
 		     a non-zero size.  A zero size may mean that the
@@ -566,6 +593,12 @@ lookup_minimal_symbol_by_pc_section (COR
   return (best_symbol);
 }
 
+struct minimal_symbol *
+lookup_minimal_symbol_by_pc_section (CORE_ADDR pc, asection *section)
+{
+  return lookup_minimal_symbol_by_pc_section_1 (pc, section, 0);
+}
+
 /* Backward compatibility: search through the minimal symbol table 
    for a matching PC (no section given) */
 
@@ -1019,7 +1052,13 @@ msymbols_sort (struct objfile *objfile)
 struct minimal_symbol *
 lookup_solib_trampoline_symbol_by_pc (CORE_ADDR pc)
 {
-  struct minimal_symbol *msymbol = lookup_minimal_symbol_by_pc (pc);
+  struct obj_section *section = find_pc_section (pc);
+  struct minimal_symbol *msymbol;
+
+  if (section == NULL)
+    return NULL;
+  msymbol = lookup_minimal_symbol_by_pc_section_1 (pc, section->the_bfd_section,
+						   1);
 
   if (msymbol != NULL && MSYMBOL_TYPE (msymbol) == mst_solib_trampoline)
     return msymbol;

Re: Shared library call problems on PowerPC with current binutils/gdb

[Ulrich Weigand]

Daniel Jacobowitz wrote:

> 2008-05-03  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> 	* elfread.c (elf_symtab_read): Create trampolines for @plt symbols.
> 	* minsyms.c (lookup_minimal_symbol_by_pc_section_1): Renamed from
> 	lookup_minimal_symbol_by_pc_section.  Prefer trampolines if requested.
> 	(lookup_minimal_symbol_by_pc_section): Use
> 	lookup_minimal_symbol_by_pc_section_1.
> 	(lookup_solib_trampoline_symbol_by_pc): Likewise.

Now that Alan's synthetic symbol patch is in, this patch fixed a
number of regressions on both ppc and ppc64.  In particular I need
at least the minsyms.c part to fix regressions introduced by Alan's
patch (because we now have both the @plt synthetic symbol *and* and
old-style solib_trampoline at the same address ...).

Were you planning on installing this patch, or are you still looking
for some other solution?

Bye,
Ulrich

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

Re: Shared library call problems on PowerPC with current binutils/gdb

[Daniel Jacobowitz]

On Wed, May 14, 2008 at 08:05:28PM +0200, Ulrich Weigand wrote:
> Now that Alan's synthetic symbol patch is in, this patch fixed a
> number of regressions on both ppc and ppc64.  In particular I need
> at least the minsyms.c part to fix regressions introduced by Alan's
> patch (because we now have both the @plt synthetic symbol *and* and
> old-style solib_trampoline at the same address ...).
> 
> Were you planning on installing this patch, or are you still looking
> for some other solution?

I was waiting to hear from you; I think the limitations of the patch
are annoying but acceptable.  Maybe someone will be inspired to
improve it later.  I'll install it now.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Shared library call problems on PowerPC with current binutils/gdb

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> On Wed, May 14, 2008 at 08:05:28PM +0200, Ulrich Weigand wrote:
> > Now that Alan's synthetic symbol patch is in, this patch fixed a
> > number of regressions on both ppc and ppc64.  In particular I need
> > at least the minsyms.c part to fix regressions introduced by Alan's
> > patch (because we now have both the @plt synthetic symbol *and* and
> > old-style solib_trampoline at the same address ...).
> > 
> > Were you planning on installing this patch, or are you still looking
> > for some other solution?
> 
> I was waiting to hear from you; I think the limitations of the patch
> are annoying but acceptable.  Maybe someone will be inspired to
> improve it later.  I'll install it now.

Thanks!

Bye,
Ulrich

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