PowerPC64 synthetic syms

PowerPC64 synthetic syms

[Alan Modra]

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

Re: PowerPC64 synthetic syms

[Andreas Schwab]

Alan Modra <amodra@bigpond.net.au> writes:

> 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.

I think you want to apply that to the gdb-6.5 branch as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PowerPC64 synthetic syms

[Alan Modra]

On Tue, May 23, 2006 at 02:09:42PM +0200, Andreas Schwab wrote:
> Alan Modra <amodra@bigpond.net.au> writes:
> 
> > 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.
> 
> I think you want to apply that to the gdb-6.5 branch as well.

Probably.  I'll need an OK from the relevant gdb authority.

http://sources.redhat.com/ml/binutils/2006-05/msg00389.html

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: PowerPC64 synthetic syms

[Daniel Jacobowitz]

On Wed, May 24, 2006 at 09:06:57AM +0930, Alan Modra wrote:
> On Tue, May 23, 2006 at 02:09:42PM +0200, Andreas Schwab wrote:
> > Alan Modra <amodra@bigpond.net.au> writes:
> > 
> > > 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.
> > 
> > I think you want to apply that to the gdb-6.5 branch as well.
> 
> Probably.  I'll need an OK from the relevant gdb authority.
> 
> http://sources.redhat.com/ml/binutils/2006-05/msg00389.html

Yes Please.

-- 
Daniel Jacobowitz
CodeSourcery