PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[H.J. Lu]

Hi,

This patch avoids reporting undefined symbols referenced from plugin
dummy.  Any objections?

Thanks.


H.J.
---
--
bfd/

2011-02-01  H.J. Lu  <hongjiu.lu@intel.com>

	PR ld/12277
	* bfd.c (BFD_PLUGIN_DUMMY): New.
	(BFD_FLAGS_SAVED): Add BFD_PLUGIN_DUMMY.
	(BFD_FLAGS_FOR_BFD_USE_MASK): Likewise.
	* bfd-in2.h: Regenerated.

	* elflink.c (elf_link_output_extsym): Don't report undefined
	symbols referenced from plugin dummy.

ld/

2011-02-01  H.J. Lu  <hongjiu.lu@intel.com>

	PR ld/12277
	* ldfile.c (ldfile_try_open_bfd): Set BFD_PLUGIN_DUMMY on dummy
	IR input.
	* ldmain.c (add_archive_element): Likewise.

	* plugin.c (IRONLY_SUFFIX): Removed.
	(IRONLY_SUFFIX_LEN): Likewise.
	(plugin_get_ir_dummy_bfd): Updated.  Set BFD_PLUGIN_DUMMY on
	dummy IR input.
	(is_ir_dummy_bfd): Check BFD_PLUGIN_DUMMY.
	(get_symbols): Re-indent.

diff --git a/bfd/bfd-in2.h b/bfd/bfd-in2.h
index 84fc75d..e360c06 100644
--- a/bfd/bfd-in2.h
+++ b/bfd/bfd-in2.h
@@ -5096,14 +5096,18 @@ struct bfd
   /* Decompress sections in this BFD.  */
 #define BFD_DECOMPRESS 0x10000
 
+  /* This BFD is a dummy bfd used by the linker plugin.  */
+#define BFD_PLUGIN_DUMMY 0x20000
+
   /* Flags bits to be saved in bfd_preserve_save.  */
 #define BFD_FLAGS_SAVED \
-  (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS)
+  (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS | BFD_PLUGIN_DUMMY)
 
   /* Flags bits which are for BFD use only.  */
 #define BFD_FLAGS_FOR_BFD_USE_MASK \
   (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS | BFD_LINKER_CREATED \
-   | BFD_TRADITIONAL_FORMAT | BFD_DETERMINISTIC_OUTPUT)
+   | BFD_TRADITIONAL_FORMAT | BFD_DETERMINISTIC_OUTPUT \
+   | BFD_PLUGIN_DUMMY)
 
   /* Currently my_archive is tested before adding origin to
      anything. I believe that this can become always an add of
diff --git a/bfd/bfd.c b/bfd/bfd.c
index 77582ec..c1bc6cc 100644
--- a/bfd/bfd.c
+++ b/bfd/bfd.c
@@ -157,14 +157,18 @@ CODE_FRAGMENT
 .  {* Decompress sections in this BFD.  *}
 .#define BFD_DECOMPRESS 0x10000
 .
+.  {* This BFD is a dummy bfd used by the linker plugin.  *}
+.#define BFD_PLUGIN_DUMMY 0x20000
+.
 .  {* Flags bits to be saved in bfd_preserve_save.  *}
 .#define BFD_FLAGS_SAVED \
-.  (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS)
+.  (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS | BFD_PLUGIN_DUMMY)
 .
 .  {* Flags bits which are for BFD use only.  *}
 .#define BFD_FLAGS_FOR_BFD_USE_MASK \
 .  (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS | BFD_LINKER_CREATED \
-.   | BFD_TRADITIONAL_FORMAT | BFD_DETERMINISTIC_OUTPUT)
+.   | BFD_TRADITIONAL_FORMAT | BFD_DETERMINISTIC_OUTPUT \
+.   | BFD_PLUGIN_DUMMY)
 .
 .  {* Currently my_archive is tested before adding origin to
 .     anything. I believe that this can become always an add of
diff --git a/bfd/elflink.c b/bfd/elflink.c
index 79256bf..9d86019 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -8872,7 +8872,8 @@ elf_link_output_extsym (struct elf_link_hash_entry *h, void *data)
       && ELF_ST_VISIBILITY (sym.st_other) != STV_DEFAULT
       && ELF_ST_BIND (sym.st_info) != STB_WEAK
       && h->root.type == bfd_link_hash_undefined
-      && !h->def_regular)
+      && !h->def_regular
+      && (h->root.u.undef.abfd->flags & BFD_PLUGIN_DUMMY) == 0)
     {
       const char *msg;
 
diff --git a/ld/ldfile.c b/ld/ldfile.c
index a9a6954..29e2a9c 100644
--- a/ld/ldfile.c
+++ b/ld/ldfile.c
@@ -340,6 +340,7 @@ success:
 	      entry->the_bfd = file.handle;
 	      entry->claimed = TRUE;
 	      bfd_make_readable (entry->the_bfd);
+	      entry->the_bfd->flags |= BFD_PLUGIN_DUMMY;
 	    }
 	  else
 	    {
diff --git a/ld/ldmain.c b/ld/ldmain.c
index 19c42d9..c1ff7ca 100644
--- a/ld/ldmain.c
+++ b/ld/ldmain.c
@@ -835,6 +835,7 @@ add_archive_element (struct bfd_link_info *info,
 	      input->the_bfd = file.handle;
 	      input->claimed = TRUE;
 	      bfd_make_readable (input->the_bfd);
+	      input->the_bfd->flags |= BFD_PLUGIN_DUMMY;
 	      *subsbfd = input->the_bfd;
 	    }
 	  else
diff --git a/ld/plugin.c b/ld/plugin.c
index b285787..87bcce6 100644
--- a/ld/plugin.c
+++ b/ld/plugin.c
@@ -36,15 +36,6 @@
 #include <Windows.h>
 #endif
 
-/* The suffix to append to the name of the real (claimed) object file
-   when generating a dummy BFD to hold the IR symbols sent from the
-   plugin.  */
-#define IRONLY_SUFFIX		".ironly\004"
-
-/* This is sizeof an array of chars, not sizeof a const char *.  We
-   also have to avoid inadvertently counting the trailing NUL.  */
-#define IRONLY_SUFFIX_LEN	(sizeof (IRONLY_SUFFIX) - 1)
-
 /* Stores a single argument passed to a plugin.  */
 typedef struct plugin_arg
 {
@@ -233,12 +224,12 @@ plugin_get_ir_dummy_bfd (const char *name, bfd *srctemplate)
   bfd *abfd;
 
   bfd_use_reserved_id = 1;
-  abfd = bfd_create (concat (name, IRONLY_SUFFIX, (const char *)NULL),
-		     srctemplate);
+  abfd = bfd_create (name, srctemplate);
   bfd_set_arch_info (abfd, bfd_get_arch_info (srctemplate));
   bfd_make_writable (abfd);
   bfd_copy_private_bfd_data (srctemplate, abfd);
   bfd_set_gp_size (abfd, bfd_get_gp_size (abfd));
+  abfd->flags |= BFD_PLUGIN_DUMMY;
   /* Create a minimal set of sections to own the symbols.  */
   sec = bfd_make_section_old_way (abfd, ".text");
   bfd_set_section_flags (abfd, sec,
@@ -253,14 +244,9 @@ plugin_get_ir_dummy_bfd (const char *name, bfd *srctemplate)
 static bfd_boolean
 is_ir_dummy_bfd (const bfd *abfd)
 {
-  size_t namlen;
-
   if (abfd == NULL)
     return FALSE;
-  namlen = strlen (abfd->filename);
-  if (namlen < IRONLY_SUFFIX_LEN)
-    return FALSE;
-  return !strcmp (abfd->filename + namlen - IRONLY_SUFFIX_LEN, IRONLY_SUFFIX);
+  return (abfd->flags & BFD_PLUGIN_DUMMY) != 0;
 }
 
 /* Helpers to convert between BFD and GOLD symbol formats.  */
@@ -535,9 +521,9 @@ get_symbols (const void *handle, int nsyms, struct ld_plugin_symbol *syms)
 	}
 
       /* Was originally def, weakdef, or common, but has been pre-empted.  */
-      syms[n].resolution = is_ir_dummy_bfd (owner_sec->owner)
-	? LDPR_PREEMPTED_IR
-	: LDPR_PREEMPTED_REG;
+      syms[n].resolution = (is_ir_dummy_bfd (owner_sec->owner)
+			    ? LDPR_PREEMPTED_IR
+			    : LDPR_PREEMPTED_REG);
     }
   return LDPS_OK;
 }

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Dave Korn]

On 01/02/2011 20:38, H.J. Lu wrote:
> Hi,
> 
> This patch avoids reporting undefined symbols referenced from plugin
> dummy.  Any objections?

  I'm working on a different plan that I think would be more complete and
requires only modifying ld.  Can you see any reason why this would not work:

  After reading all input files, but before calling the plugin's
all_symbols_read hook, run down the list of undefs; find any that came
originally from IR-only dummy BFDs; delete them by setting the type of the
link hash entry back to bfd_hash_new and marking the section they came from
SEC_EXCLUDE; finally call bfd_link_repair_undef_list to remove them from the
undefs chain.

  I'd rather do it that way if it works.

    cheers,
      DaveK

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[H.J. Lu]

On Tue, Feb 1, 2011 at 1:36 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 01/02/2011 20:38, H.J. Lu wrote:
>> Hi,
>>
>> This patch avoids reporting undefined symbols referenced from plugin
>> dummy.  Any objections?
>
>  I'm working on a different plan that I think would be more complete and
> requires only modifying ld.  Can you see any reason why this would not work:
>
>  After reading all input files, but before calling the plugin's
> all_symbols_read hook, run down the list of undefs; find any that came
> originally from IR-only dummy BFDs; delete them by setting the type of the
> link hash entry back to bfd_hash_new and marking the section they came from
> SEC_EXCLUDE; finally call bfd_link_repair_undef_list to remove them from the
> undefs chain.
>
>  I'd rather do it that way if it works.
>

It may work. But do you really need IRONLY_SUFFIX and
IRONLY_SUFFIX_LEN?

-- 
H.J.

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Dave Korn]

On 01/02/2011 21:18, H.J. Lu wrote:
> 
> It may work. But do you really need IRONLY_SUFFIX and
> IRONLY_SUFFIX_LEN?

  Perhaps not, but that's orthogonal; let's separate the two issues.  (Also,
it would still be nice if we could perhaps avoid changing bfd but find some
other way to recognize an IR dummy BFD when we see one; I'm not certain
whether that's possible yet though.)

    cheers,
      DaveK

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[H.J. Lu]

On Tue, Feb 1, 2011 at 1:50 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 01/02/2011 21:18, H.J. Lu wrote:
>>
>> It may work. But do you really need IRONLY_SUFFIX and
>> IRONLY_SUFFIX_LEN?
>
>  Perhaps not, but that's orthogonal; let's separate the two issues.  (Also,
> it would still be nice if we could perhaps avoid changing bfd but find some
> other way to recognize an IR dummy BFD when we see one; I'm not certain
> whether that's possible yet though.)
>

Not really orthogonal.  Current way for checking IR dummy BFD is
very expensive and unnecessary. It should be fixed first.


-- 
H.J.

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Dave Korn]

On 01/02/2011 21:28, H.J. Lu wrote:
> On Tue, Feb 1, 2011 at 1:50 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>> On 01/02/2011 21:18, H.J. Lu wrote:
>>> It may work. But do you really need IRONLY_SUFFIX and
>>> IRONLY_SUFFIX_LEN?
>>  Perhaps not, but that's orthogonal; let's separate the two issues.  (Also,
>> it would still be nice if we could perhaps avoid changing bfd but find some
>> other way to recognize an IR dummy BFD when we see one; I'm not certain
>> whether that's possible yet though.)
>>
> 
> Not really orthogonal.

  Have no idea what you're talking about.  Orthogonal means it can be
considered separately.  The mechanism by which we detect an IR file is
entirely orthogonal to the question of what we subsequently *do* with it.

    cheers,
      DaveK

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Dave Korn]

On 01/02/2011 21:28, H.J. Lu wrote:
> On Tue, Feb 1, 2011 at 1:50 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>> On 01/02/2011 21:18, H.J. Lu wrote:
>>> It may work. But do you really need IRONLY_SUFFIX and
>>> IRONLY_SUFFIX_LEN?
>>  Perhaps not, but that's orthogonal; let's separate the two issues.  (Also,
>> it would still be nice if we could perhaps avoid changing bfd but find some
>> other way to recognize an IR dummy BFD when we see one; I'm not certain
>> whether that's possible yet though.)
>>
> 
> Not really orthogonal.  Current way for checking IR dummy BFD is
> very expensive and unnecessary. It should be fixed first.

  As an alternative to adding a flag in BFD, we could equally just keep a hash
table of IR-only BFDs in ld/plugin.c and recognise them that way instead.
What do you think?

    cheers,
      DaveK

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[H.J. Lu]

On Tue, Feb 1, 2011 at 2:57 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 01/02/2011 21:28, H.J. Lu wrote:
>> On Tue, Feb 1, 2011 at 1:50 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>> On 01/02/2011 21:18, H.J. Lu wrote:
>>>> It may work. But do you really need IRONLY_SUFFIX and
>>>> IRONLY_SUFFIX_LEN?
>>>  Perhaps not, but that's orthogonal; let's separate the two issues.  (Also,
>>> it would still be nice if we could perhaps avoid changing bfd but find some
>>> other way to recognize an IR dummy BFD when we see one; I'm not certain
>>> whether that's possible yet though.)
>>>
>>
>> Not really orthogonal.  Current way for checking IR dummy BFD is
>> very expensive and unnecessary. It should be fixed first.
>
>  As an alternative to adding a flag in BFD, we could equally just keep a hash
> table of IR-only BFDs in ld/plugin.c and recognise them that way instead.
> What do you think?
>

It is still expensive. We should use a bit in BFD, which also makes
that info available to BFD.

-- 
H.J.

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Dave Korn]

On 01/02/2011 22:36, H.J. Lu wrote:
> On Tue, Feb 1, 2011 at 2:57 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>> On 01/02/2011 21:28, H.J. Lu wrote:
>>> On Tue, Feb 1, 2011 at 1:50 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>>> On 01/02/2011 21:18, H.J. Lu wrote:
>>>>> It may work. But do you really need IRONLY_SUFFIX and
>>>>> IRONLY_SUFFIX_LEN?
>>>>  Perhaps not, but that's orthogonal; let's separate the two issues.  (Also,
>>>> it would still be nice if we could perhaps avoid changing bfd but find some
>>>> other way to recognize an IR dummy BFD when we see one; I'm not certain
>>>> whether that's possible yet though.)
>>>>
>>> Not really orthogonal.  Current way for checking IR dummy BFD is
>>> very expensive and unnecessary. It should be fixed first.
>>  As an alternative to adding a flag in BFD, we could equally just keep a hash
>> table of IR-only BFDs in ld/plugin.c and recognise them that way instead.
>> What do you think?
>>
> 
> It is still expensive. 

  You have a point, it can be called two or maybe three times per symbol.

> We should use a bit in BFD, which also makes that info available to BFD.

  Seems like layer-crossing to me.  This is the linker's plugin interface, not
BFD's; the information belongs to BFD's client application, not BFD.

  I need to see what we're doing with the BFD usrdata field.  A quick grep
suggests it points to the input statement, which if it can be relied on will
entirely obviate the need for either the suffix or an extra flag in BFD.

    cheers,
      DaveK

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[H.J. Lu]

On Tue, Feb 1, 2011 at 3:11 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> On 01/02/2011 22:36, H.J. Lu wrote:
>> On Tue, Feb 1, 2011 at 2:57 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>> On 01/02/2011 21:28, H.J. Lu wrote:
>>>> On Tue, Feb 1, 2011 at 1:50 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>>>> On 01/02/2011 21:18, H.J. Lu wrote:
>>>>>> It may work. But do you really need IRONLY_SUFFIX and
>>>>>> IRONLY_SUFFIX_LEN?
>>>>>  Perhaps not, but that's orthogonal; let's separate the two issues.  (Also,
>>>>> it would still be nice if we could perhaps avoid changing bfd but find some
>>>>> other way to recognize an IR dummy BFD when we see one; I'm not certain
>>>>> whether that's possible yet though.)
>>>>>
>>>> Not really orthogonal.  Current way for checking IR dummy BFD is
>>>> very expensive and unnecessary. It should be fixed first.
>>>  As an alternative to adding a flag in BFD, we could equally just keep a hash
>>> table of IR-only BFDs in ld/plugin.c and recognise them that way instead.
>>> What do you think?
>>>
>>
>> It is still expensive.
>
>  You have a point, it can be called two or maybe three times per symbol.
>
>> We should use a bit in BFD, which also makes that info available to BFD.
>
>  Seems like layer-crossing to me.  This is the linker's plugin interface, not
> BFD's; the information belongs to BFD's client application, not BFD.
>
>  I need to see what we're doing with the BFD usrdata field.  A quick grep
> suggests it points to the input statement, which if it can be relied on will
> entirely obviate the need for either the suffix or an extra flag in BFD.
>

Well, part of linking is implemented in BFD. BFD may use the plugin
dummy information.

-- 
H.J.

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Dave Korn]

On 01/02/2011 23:11, Dave Korn wrote:

>   I need to see what we're doing with the BFD usrdata field.  A quick grep
> suggests it points to the input statement, which if it can be relied on will
> entirely obviate the need for either the suffix or an extra flag in BFD.

  No, or not directly, anyway; it isn't set early enough.

    cheers,
      DaveK

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Dave Korn]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On 01/02/2011 23:18, Dave Korn wrote:
> On 01/02/2011 23:11, Dave Korn wrote:
> 
>>   I need to see what we're doing with the BFD usrdata field.  A quick grep
>> suggests it points to the input statement, which if it can be relied on will
>> entirely obviate the need for either the suffix or an extra flag in BFD.
> 
>   No, or not directly, anyway; it isn't set early enough.

  Actually, I spoke too soon.  It gets set when load_symbols calls
ldlang_add_file, which happens before the actual call to bfd_link_add_symbols,
so I think it should be safe.  Was going to send this in along with the rest
of the patches as a bundle later, but here's a preview.

    cheers,
      DaveK


[-- Attachment #2: 003ld-plugin-api-no-ironly-suffix.diff --]
[-- Type: text/x-c, Size: 2106 bytes --]

From fc7521535ba78da4c5601fe98cb5b2409f61f352 Mon Sep 17 00:00:00 2001
From: Dave Korn <dave.korn.cygwin@gmail.com>
Date: Wed, 2 Feb 2011 04:11:59 +0000
Subject: [PATCH] ld/ChangeLog:

2011-02-01  Dave Korn  <...

	* plugin.c (IRONLY_SUFFIX): Delete.
	(IRONLY_SUFFIX_LEN): Likewise.
	(plugin_get_ir_dummy_bfd): Don't append IRONLY_SUFFIX.
	(is_ir_dummy_bfd): Don't look for it; check claimed flag of enclosing
	lang input statement instead.
---
 ld/plugin.c |   23 ++++-------------------
 1 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/ld/plugin.c b/ld/plugin.c
index cd8aeb9..e6cc436 100644
--- a/ld/plugin.c
+++ b/ld/plugin.c
@@ -36,15 +36,6 @@
 #include <Windows.h>
 #endif
 
-/* The suffix to append to the name of the real (claimed) object file
-   when generating a dummy BFD to hold the IR symbols sent from the
-   plugin.  */
-#define IRONLY_SUFFIX		".ironly\004"
-
-/* This is sizeof an array of chars, not sizeof a const char *.  We
-   also have to avoid inadvertently counting the trailing NUL.  */
-#define IRONLY_SUFFIX_LEN	(sizeof (IRONLY_SUFFIX) - 1)
-
 /* Stores a single argument passed to a plugin.  */
 typedef struct plugin_arg
 {
@@ -236,8 +227,7 @@ plugin_get_ir_dummy_bfd (const char *name, bfd *srctemplate)
   bfd *abfd;
 
   bfd_use_reserved_id = 1;
-  abfd = bfd_create (concat (name, IRONLY_SUFFIX, (const char *)NULL),
-		     srctemplate);
+  abfd = bfd_create (name, srctemplate);
   bfd_set_arch_info (abfd, bfd_get_arch_info (srctemplate));
   bfd_make_writable (abfd);
   bfd_copy_private_bfd_data (srctemplate, abfd);
@@ -256,14 +246,9 @@ plugin_get_ir_dummy_bfd (const char *name, bfd *srctemplate)
 static bfd_boolean
 is_ir_dummy_bfd (const bfd *abfd)
 {
-  size_t namlen;
+  ASSERT(abfd->usrdata);
+  return ((lang_input_statement_type *)(abfd->usrdata))->claimed;
 
-  if (abfd == NULL)
-    return FALSE;
-  namlen = strlen (abfd->filename);
-  if (namlen < IRONLY_SUFFIX_LEN)
-    return FALSE;
-  return !strcmp (abfd->filename + namlen - IRONLY_SUFFIX_LEN, IRONLY_SUFFIX);
 }
 
 /* Helpers to convert between BFD and GOLD symbol formats.  */

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Alan Modra]

On Thu, Feb 03, 2011 at 06:20:03AM +0000, Dave Korn wrote:
> -  abfd = bfd_create (concat (name, IRONLY_SUFFIX, (const char *)NULL),
> -		     srctemplate);
> +  abfd = bfd_create (name, srctemplate);

For the sake of error messages like the one in
http://sourceware.org/ml/binutils/2011-02/msg00037.html, I think it
would be better to keep the name suffix.  The change to
is_ir_dummy_bfd is OK to commit.

-- 
Alan Modra
Australia Development Lab, IBM

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[H.J. Lu]

On Fri, Feb 4, 2011 at 6:07 PM, Alan Modra <amodra@gmail.com> wrote:
> On Thu, Feb 03, 2011 at 06:20:03AM +0000, Dave Korn wrote:
>> -  abfd = bfd_create (concat (name, IRONLY_SUFFIX, (const char *)NULL),
>> -                  srctemplate);
>> +  abfd = bfd_create (name, srctemplate);
>
> For the sake of error messages like the one in
> http://sourceware.org/ml/binutils/2011-02/msg00037.html, I think it
> would be better to keep the name suffix.  The change to
> is_ir_dummy_bfd is OK to commit.
>

That is a linker error, which is intended for linker developers.
I don't think a suffix makes a big difference here.

-- 
H.J.

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Alan Modra]

On Sat, Feb 05, 2011 at 06:21:42AM -0800, H.J. Lu wrote:
> On Fri, Feb 4, 2011 at 6:07 PM, Alan Modra <amodra@gmail.com> wrote:
> > On Thu, Feb 03, 2011 at 06:20:03AM +0000, Dave Korn wrote:
> >> -  abfd = bfd_create (concat (name, IRONLY_SUFFIX, (const char *)NULL),
> >> -                  srctemplate);
> >> +  abfd = bfd_create (name, srctemplate);
> >
> > For the sake of error messages like the one in
> > http://sourceware.org/ml/binutils/2011-02/msg00037.html, I think it
> > would be better to keep the name suffix.  The change to
> > is_ir_dummy_bfd is OK to commit.
> >
> 
> That is a linker error, which is intended for linker developers.

I was thinking of both bug reports and developers when I suggested
keeping the suffix.

> I don't think a suffix makes a big difference here.

True.

-- 
Alan Modra
Australia Development Lab, IBM

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Dave Korn]

(Back after a couple of days offline due to a motherboard blow-out...)

On 07/02/2011 01:36, Alan Modra wrote:
> On Sat, Feb 05, 2011 at 06:21:42AM -0800, H.J. Lu wrote:
>> On Fri, Feb 4, 2011 at 6:07 PM, Alan Modra <amodra@gmail.com> wrote:
>>> On Thu, Feb 03, 2011 at 06:20:03AM +0000, Dave Korn wrote:
>>>> -  abfd = bfd_create (concat (name, IRONLY_SUFFIX, (const char *)NULL),
>>>> -                  srctemplate);
>>>> +  abfd = bfd_create (name, srctemplate);
>>> For the sake of error messages like the one in
>>> http://sourceware.org/ml/binutils/2011-02/msg00037.html, I think it
>>> would be better to keep the name suffix.  The change to
>>> is_ir_dummy_bfd is OK to commit.
>>>
>> That is a linker error, which is intended for linker developers.
> 
> I was thinking of both bug reports and developers when I suggested
> keeping the suffix.
> 
>> I don't think a suffix makes a big difference here.
> 
> True.

  I think it might be nice to change it to something human-readable, now that
it's not being used as a discriminator any more.  What do you two think about
something like

#define IRONLY_SUFFIX		" (symbol from plugin)"

... that?

    cheers,
      DaveK

Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Alan Modra]

On Wed, Feb 09, 2011 at 02:40:17PM +0000, Dave Korn wrote:
>   I think it might be nice to change it to something human-readable, now that
> it's not being used as a discriminator any more.  What do you two think about
> something like
> 
> #define IRONLY_SUFFIX		" (symbol from plugin)"
> 
> ... that?

Fine by me.

-- 
Alan Modra
Australia Development Lab, IBM