(no subject)

[Nick Clifton]

Hi Guys,

  I am checking in the patch below to handle the situation where the
  plugin handler is asked to canonicalize a weak symbol of an unknown
  type.  This situation actually occurred in real life due to a bug in
  the LTO plugin, and that bug was made worse by the code in the handler
  not detecting it and leaving the section pointer set to NULL.

Cheers
  Nick

bfd/ChangeLog
2020-09-08  Nick Clifton  <nickc@redhat.com>

	* plugin.c (bfd_plugin_canonicalize_symtab): Handle the case of an
	unrecognized symbol type in a weak definition.

diff --git a/bfd/plugin.c b/bfd/plugin.c
index 593e277747..bed98520da 100644
--- a/bfd/plugin.c
+++ b/bfd/plugin.c
@@ -640,6 +640,8 @@ bfd_plugin_canonicalize_symtab (bfd *abfd,
 	  if (current_plugin->has_symbol_type)
 	    switch (syms[i].symbol_type)
 	      {
+	      default:
+		/* FIXME: Should we issue an error here ?  */
 	      case LDST_UNKNOWN:
 		/* What is the best fake section for LDST_UNKNOWN?  */
 	      case LDST_FUNCTION:

plugin handler patch

[Jeff Law]

On Tue, 2020-09-08 at 09:48 +0100, Nick Clifton via Binutils wrote:
> Hi Guys,
> 
>   I am checking in the patch below to handle the situation where the
>   plugin handler is asked to canonicalize a weak symbol of an unknown
>   type.  This situation actually occurred in real life due to a bug in
>   the LTO plugin, and that bug was made worse by the code in the handler
>   not detecting it and leaving the section pointer set to NULL.
> 
> Cheers
>   Nick
> 
> bfd/ChangeLog
> 2020-09-08  Nick Clifton  <nickc@redhat.com>
> 
> 	* plugin.c (bfd_plugin_canonicalize_symtab): Handle the case of an
> 	unrecognized symbol type in a weak definition.
If I'm reading this correctly, it's our position that the nm fault this fixes is
really a problem in the linker plugin.  Right?  Meaning there's no significant
pressure to get this into rawhide.  We can just pick it up via the usual updates
when they happen.

Thanks,
Jeff

Re: plugin handler patch

[Nick Clifton]

Hi Jeff,

> If I'm reading this correctly, it's our position that the nm fault this fixes is
> really a problem in the linker plugin.  Right?

Right - this is just a fix to ensure better behaviour in the linker for
when the plugin does go wrong.  

> Meaning there's no significant
> pressure to get this into rawhide.  We can just pick it up via the usual updates
> when they happen.

Well, if we do not fix the lto plugin soon, then importing the binutils patch
will make the linker less likely to seg-fault.  But not by much ... :-)

Cheers
  Nick

Re: plugin handler patch

[Jeff Law]

On Tue, 2020-09-08 at 16:26 +0100, Nick Clifton wrote:
> Hi Jeff,
> 
> > If I'm reading this correctly, it's our position that the nm fault this fixes is
> > really a problem in the linker plugin.  Right?
> 
> Right - this is just a fix to ensure better behaviour in the linker for
> when the plugin does go wrong.  
> 
> > Meaning there's no significant
> > pressure to get this into rawhide.  We can just pick it up via the usual updates
> > when they happen.
> 
> Well, if we do not fix the lto plugin soon, then importing the binutils patch
> will make the linker less likely to seg-fault.  But not by much ... :-)
I'm going to work with Jakub to figure out a reasonable plan.  There's 3 patches
I'm aware of that would be useful to get into rawhide.  The plugin patch, plus
two of Jakub's that fix gcc bugs.

The trick is with 24+ hour turnaround times, we don't want to unnecessarily spin
Fedora builds.

Jeff