[PATCH] prevent core dump for multiple def symbols

[PATCH] prevent core dump for multiple def symbols

[Fergal Daly]

I have a .so file that makes gdb dump core. The problem shows up in
bfd/linker.c:1800

if (! ((*info->callbacks->multiple_definition)
  (info, h->root.string, msec->owner, msec, mval,
  abfd, section, value)))
    return FALSE;

because info->callbacks->multiple_definition is null.

I have no idea if this patch is "the right thing" but it allows me to debug
my app. It just sets the callback to a dummy callback which returns TRUE
when the link_info is being created. I presume this is OK because all the
other callbacks are set to dummies too.

This was logged as bug 1668, hopefully this is a fix for it.

Patch below,

F


--- ./bfd/simple.c.orig	2004-06-11 15:32:40.620497552 +0100
+++ ./bfd/simple.c	2004-06-11 15:18:42.043980560 +0100
@@ -78,6 +78,19 @@
   return TRUE;
 }
 
+static bfd_boolean
+simple_dummy_multiple_definition (struct bfd_link_info *link_info ATTRIBUTE_UNUSED,
+			       const char *name ATTRIBUTE_UNUSED,
+			       bfd *obfd ATTRIBUTE_UNUSED,
+			       asection *osec,
+			       bfd_vma oval ATTRIBUTE_UNUSED,
+			       bfd *nbfd ATTRIBUTE_UNUSED,
+			       asection *nsec ATTRIBUTE_UNUSED,
+			       bfd_vma nval ATTRIBUTE_UNUSED)
+{
+  return TRUE;
+}
+
 struct saved_output_info
 {
   bfd_vma offset;
@@ -171,6 +184,7 @@
   callbacks.reloc_overflow = simple_dummy_reloc_overflow;
   callbacks.reloc_dangerous = simple_dummy_reloc_dangerous;
   callbacks.unattached_reloc = simple_dummy_unattached_reloc;
+  callbacks.multiple_definition = simple_dummy_multiple_definition;
 
   memset (&link_order, 0, sizeof (link_order));
   link_order.next = NULL;

Re: [PATCH] prevent core dump for multiple def symbols

[Daniel Jacobowitz]

The files in bfd/ are maintained as part of GNU Binutils, so you need
to ask on the binutils list about this patch.

It seems obvious and correct to me.  Is multiple_definition a recent
callback or did I just miss it when I wrote simple.c?  [I won't even
ask how you have a shared library with multiple definitions of a
dynamic symbol.]

On Fri, Jun 11, 2004 at 03:45:26PM +0100, Fergal Daly wrote:
> I have a .so file that makes gdb dump core. The problem shows up in
> bfd/linker.c:1800
> 
> if (! ((*info->callbacks->multiple_definition)
>   (info, h->root.string, msec->owner, msec, mval,
>   abfd, section, value)))
>     return FALSE;
> 
> because info->callbacks->multiple_definition is null.
> 
> I have no idea if this patch is "the right thing" but it allows me to debug
> my app. It just sets the callback to a dummy callback which returns TRUE
> when the link_info is being created. I presume this is OK because all the
> other callbacks are set to dummies too.
> 
> This was logged as bug 1668, hopefully this is a fix for it.
> 
> Patch below,
> 
> F
> 
> 
> --- ./bfd/simple.c.orig	2004-06-11 15:32:40.620497552 +0100
> +++ ./bfd/simple.c	2004-06-11 15:18:42.043980560 +0100
> @@ -78,6 +78,19 @@
>    return TRUE;
>  }
>  
> +static bfd_boolean
> +simple_dummy_multiple_definition (struct bfd_link_info *link_info ATTRIBUTE_UNUSED,
> +			       const char *name ATTRIBUTE_UNUSED,
> +			       bfd *obfd ATTRIBUTE_UNUSED,
> +			       asection *osec,
> +			       bfd_vma oval ATTRIBUTE_UNUSED,
> +			       bfd *nbfd ATTRIBUTE_UNUSED,
> +			       asection *nsec ATTRIBUTE_UNUSED,
> +			       bfd_vma nval ATTRIBUTE_UNUSED)
> +{
> +  return TRUE;
> +}
> +
>  struct saved_output_info
>  {
>    bfd_vma offset;
> @@ -171,6 +184,7 @@
>    callbacks.reloc_overflow = simple_dummy_reloc_overflow;
>    callbacks.reloc_dangerous = simple_dummy_reloc_dangerous;
>    callbacks.unattached_reloc = simple_dummy_unattached_reloc;
> +  callbacks.multiple_definition = simple_dummy_multiple_definition;
>  
>    memset (&link_order, 0, sizeof (link_order));
>    link_order.next = NULL;
> 

-- 
Daniel Jacobowitz

Re: [PATCH] prevent core dump for multiple def symbols

[Fergal Daly]

On Fri, Jun 11, 2004 at 10:53:41AM -0400, Daniel Jacobowitz wrote:
> The files in bfd/ are maintained as part of GNU Binutils, so you need
> to ask on the binutils list about this patch.

Thanks.

> It seems obvious and correct to me.  Is multiple_definition a recent
> callback or did I just miss it when I wrote simple.c?  [I won't even
> ask how you have a shared library with multiple definitions of a
> dynamic symbol.]

I'll tell you anyway :-) It's a .so produced by Borland's Kylix Object
Pascal compiler. Unfortunately their debugger is incapable of debugging it
(although the same app on windows has no problem). Earlier versions of gdb
seemed to handle it ok.

Is it totally bizarre to have this situation? I know very little about this
sort of stuff. Perhaps there's something wacky in the Pascal source code
that's causing this. If you can think of anything that might cause this,
please let me know. Is it likely to be the linker?

Thanks,

F

Re: [PATCH] prevent core dump for multiple def symbols

[Ian Lance Taylor]

Daniel Jacobowitz <drow@false.org> writes:

> It seems obvious and correct to me.  Is multiple_definition a recent
> callback or did I just miss it when I wrote simple.c?  [I won't even
> ask how you have a shared library with multiple definitions of a
> dynamic symbol.]

multiple_definition is not a recent callback.  It's been there from
the start.

I agree that for it to be called in this scenario is odd.

Ian

Re: [PATCH] prevent core dump for multiple def symbols

[Fergal Daly]

On Fri, Jun 11, 2004 at 11:39:35AM -0400, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > It seems obvious and correct to me.  Is multiple_definition a recent
> > callback or did I just miss it when I wrote simple.c?  [I won't even
> > ask how you have a shared library with multiple definitions of a
> > dynamic symbol.]
> 
> multiple_definition is not a recent callback.  It's been there from
> the start.
> 
> I agree that for it to be called in this scenario is odd.

nm myWeird.so | wc -l
11282

nm myWeird.so | cut -f 3 -d " " | sort | uniq -d | wc -l
92

so it seems Kylix is in the habit of generating multiple copies of symbols.

I think it's because of overloaded functions. I've just picked a few
duplicate symbols at random and they turned out to be overloaded.

I don't know if this is Kylix's fault or what but I hope you will consider
applying the patch anyway? There's zero chance of getting Kylix fixed :-(

Fergal

Re: [PATCH] prevent core dump for multiple def symbols

[Daniel Jacobowitz]

On Fri, Jun 11, 2004 at 10:53:41AM -0400, Daniel Jacobowitz wrote:
> The files in bfd/ are maintained as part of GNU Binutils, so you need
> to ask on the binutils list about this patch.
> 
> It seems obvious and correct to me.  Is multiple_definition a recent
> callback or did I just miss it when I wrote simple.c?  [I won't even
> ask how you have a shared library with multiple definitions of a
> dynamic symbol.]
>
> On Fri, Jun 11, 2004 at 03:45:26PM +0100, Fergal Daly wrote:
> > I have a .so file that makes gdb dump core. The problem shows up in
> > bfd/linker.c:1800
> > 
> > if (! ((*info->callbacks->multiple_definition)
> >   (info, h->root.string, msec->owner, msec, mval,
> >   abfd, section, value)))
> >     return FALSE;
> > 
> > because info->callbacks->multiple_definition is null.
> > 
> > I have no idea if this patch is "the right thing" but it allows me to debug
> > my app. It just sets the callback to a dummy callback which returns TRUE
> > when the link_info is being created. I presume this is OK because all the
> > other callbacks are set to dummies too.
> > 
> > This was logged as bug 1668, hopefully this is a fix for it.
> > 
> > Patch below,

I have belatedly checked in this patch, with some formatting fixes.
Tested on i686-pc-linux-gnu.

-- 
Daniel Jacobowitz