PATCH: fix collect2 handling of --demangle and --no-demangle

PATCH: fix collect2 handling of --demangle and --no-demangle

[Sandra Loosemore]

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

We had a bug report from a customer that the linker was ignoring the 
--demangle and --no-demangle options when generating map files. 
Moreover, it was failing in a host-dependent way; on Windows hosts, it 
was always emitting demangled names in the map file, while on Linux 
hosts, it never did.  Moreover, on Windows hosts it also ignored the 
setting of the COLLECT_NO_DEMANGLE environment variable.

This turns out to be a problem in collect2, or actually, three problems:

(1) By default, collect2 is configured to filter out --demangle and 
--no-demangle from the linker options, and it tries to do demangling on 
symbol names in stdout and stderr itself instead.  But, it is too stupid 
to know about the map file.

(2) Collect2 is trying to set COLLECT_NO_DEMANGLE to disable demangling 
in ld, but in a nonportable way that causes it to be always unset 
instead on Windows.

(3) If you configure with --with-demangler-in-ld to try to disable the 
collect2 demangling, there's another bug that causes it to ignore any 
explicit --demangle or --no-demangle options and only pay attention to 
whether or not COLLECT_NO_DEMANGLE is set.

The attached patch addresses all three problems:

(1) I've flipped the default to --with-demangler-in-ld=yes.  Note that 
configure.ac already takes care not to let this percolate through to 
collect2 without verifying that the linker is GNU ld and that it is a 
version that supports --demangle.  Perhaps back in 2004 when this option 
was first added, the ld demangling support was deemed too experimental 
to make it the default, but that's surely not the case any more.  Also, 
since this has been broken since 2004, I'm not sure there's much reason 
to be concerned with backwards compatibility, here....

(2) I fixed the COLLECT_NO_DEMANGLE environment variable setting recipe.

(3) I simplified the argument processing for --demangle and 
--no-demangle to pass them straight through to the linker when 
HAVE_LD_DEMANGLE is defined.

OK to commit?

-Sandra



2011-06-17  Sandra Loosemore  <sandra@codesourcery.com>

	gcc/
	* configure.ac (demangler_in_ld): Default to yes.
	* configure: Regenerated.
	* collect2.c (main): When HAVE_LD_DEMANGLE is defined, don't
	mess with COLLECT_NO_DEMANGLE, and just pass --demangle and
	--no-demangle options straight through to ld.  When
	HAVE_LD_DEMANGLE is not defined, set COLLECT_NO_DEMANGLE in a
	way that has the intended effect on Windows.

[-- Attachment #2: mainline.patch --]
[-- Type: text/x-patch, Size: 2455 bytes --]

Index: configure.ac
===================================================================
--- configure.ac	(revision 175123)
+++ configure.ac	(working copy)
@@ -222,7 +222,7 @@ fi
 AC_ARG_WITH(demangler-in-ld,
 [AS_HELP_STRING([--with-demangler-in-ld], [try to use demangler in GNU ld])],
 demangler_in_ld="$with_demangler_in_ld",
-demangler_in_ld=no)
+demangler_in_ld=yes)
 
 # ----------------------
 # Find default assembler
Index: configure
===================================================================
--- configure	(revision 175123)
+++ configure	(working copy)
@@ -3413,7 +3413,7 @@ fi
 if test "${with_demangler_in_ld+set}" = set; then :
   withval=$with_demangler_in_ld; demangler_in_ld="$with_demangler_in_ld"
 else
-  demangler_in_ld=no
+  demangler_in_ld=yes
 fi
 
 
Index: collect2.c
===================================================================
--- collect2.c	(revision 175123)
+++ collect2.c	(working copy)
@@ -1112,10 +1112,12 @@ main (int argc, char **argv)
 
   num_c_args = argc + 9;
 
+#ifndef HAVE_LD_DEMANGLE
   no_demangle = !! getenv ("COLLECT_NO_DEMANGLE");
 
   /* Suppress demangling by the real linker, which may be broken.  */
-  putenv (xstrdup ("COLLECT_NO_DEMANGLE="));
+  putenv (xstrdup ("COLLECT_NO_DEMANGLE=1"));
+#endif
 
 #if defined (COLLECT2_HOST_INITIALIZATION)
   /* Perform system dependent initialization, if necessary.  */
@@ -1405,12 +1407,6 @@ main (int argc, char **argv)
   /* After the first file, put in the c++ rt0.  */
 
   first_file = 1;
-#ifdef HAVE_LD_DEMANGLE
-  if (!demangle_flag && !no_demangle)
-    demangle_flag = "--demangle";
-  if (demangle_flag)
-    *ld1++ = *ld2++ = demangle_flag;
-#endif
   while ((arg = *++argv) != (char *) 0)
     {
       *ld1++ = *ld2++ = arg;
@@ -1514,16 +1510,16 @@ main (int argc, char **argv)
 	    case '-':
 	      if (strcmp (arg, "--no-demangle") == 0)
 		{
-		  demangle_flag = arg;
+#ifndef HAVE_LD_DEMANGLE
 		  no_demangle = 1;
 		  ld1--;
 		  ld2--;
+#endif
 		}
 	      else if (strncmp (arg, "--demangle", 10) == 0)
 		{
-		  demangle_flag = arg;
-		  no_demangle = 0;
 #ifndef HAVE_LD_DEMANGLE
+		  no_demangle = 0;
 		  if (arg[10] == '=')
 		    {
 		      enum demangling_styles style
@@ -1533,9 +1529,9 @@ main (int argc, char **argv)
 		      else
 			current_demangling_style = style;
 		    }
-#endif
 		  ld1--;
 		  ld2--;
+#endif
 		}
 	      else if (strncmp (arg, "--sysroot=", 10) == 0)
 		target_system_root = arg + 10;

PING Re: PATCH: fix collect2 handling of --demangle and --no-demangle

[Sandra Loosemore]

Ping?

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01368.html

> We had a bug report from a customer that the linker was ignoring the
> --demangle and --no-demangle options when generating map files.
> Moreover, it was failing in a host-dependent way; on Windows hosts,
> it was always emitting demangled names in the map file, while on
> Linux hosts, it never did.  Moreover, on Windows hosts it also
> ignored the setting of the COLLECT_NO_DEMANGLE environment variable.
>
> This turns out to be a problem in collect2, or actually, three
> problems:
>
> (1) By default, collect2 is configured to filter out --demangle and
> --no-demangle from the linker options, and it tries to do demangling
> on symbol names in stdout and stderr itself instead.  But, it is too
> stupid to know about the map file.
>
> (2) Collect2 is trying to set COLLECT_NO_DEMANGLE to disable
> demangling in ld, but in a nonportable way that causes it to be
> always unset instead on Windows.
>
> (3) If you configure with --with-demangler-in-ld to try to disable
> the collect2 demangling, there's another bug that causes it to ignore
> any explicit --demangle or --no-demangle options and only pay
> attention to whether or not COLLECT_NO_DEMANGLE is set.
>
> The attached patch addresses all three problems:
>
> (1) I've flipped the default to --with-demangler-in-ld=yes.  Note
> that configure.ac already takes care not to let this percolate
> through to collect2 without verifying that the linker is GNU ld and
> that it is a version that supports --demangle.  Perhaps back in 2004
> when this option was first added, the ld demangling support was
> deemed too experimental to make it the default, but that's surely not
> the case any more.  Also, since this has been broken since 2004, I'm
> not sure there's much reason to be concerned with backwards
> compatibility, here....
>
> (2) I fixed the COLLECT_NO_DEMANGLE environment variable setting
> recipe.
>
> (3) I simplified the argument processing for --demangle and
> --no-demangle to pass them straight through to the linker when
> HAVE_LD_DEMANGLE is defined.
>
> OK to commit?
>
> -Sandra
>
> 2011-06-17  Sandra Loosemore  <sandra@codesourcery.com>
>
>     gcc/
>     * configure.ac (demangler_in_ld): Default to yes.
>     * configure: Regenerated.
>     * collect2.c (main): When HAVE_LD_DEMANGLE is defined, don't
>     mess with COLLECT_NO_DEMANGLE, and just pass --demangle and
>     --no-demangle options straight through to ld.  When
>     HAVE_LD_DEMANGLE is not defined, set COLLECT_NO_DEMANGLE in a
>     way that has the intended effect on Windows.
>
>

PING^2 Re: PATCH: fix collect2 handling of --demangle and --no-demangle

[Sandra Loosemore]

Ping?

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01368.html

> We had a bug report from a customer that the linker was ignoring the
> --demangle and --no-demangle options when generating map files.
> Moreover, it was failing in a host-dependent way; on Windows hosts,
> it was always emitting demangled names in the map file, while on
> Linux hosts, it never did.  Moreover, on Windows hosts it also
> ignored the setting of the COLLECT_NO_DEMANGLE environment variable.
>
> This turns out to be a problem in collect2, or actually, three
> problems:
>
> (1) By default, collect2 is configured to filter out --demangle and
> --no-demangle from the linker options, and it tries to do demangling
> on symbol names in stdout and stderr itself instead.  But, it is too
> stupid to know about the map file.
>
> (2) Collect2 is trying to set COLLECT_NO_DEMANGLE to disable
> demangling in ld, but in a nonportable way that causes it to be
> always unset instead on Windows.
>
> (3) If you configure with --with-demangler-in-ld to try to disable
> the collect2 demangling, there's another bug that causes it to ignore
> any explicit --demangle or --no-demangle options and only pay
> attention to whether or not COLLECT_NO_DEMANGLE is set.
>
> The attached patch addresses all three problems:
>
> (1) I've flipped the default to --with-demangler-in-ld=yes.  Note
> that configure.ac already takes care not to let this percolate
> through to collect2 without verifying that the linker is GNU ld and
> that it is a version that supports --demangle.  Perhaps back in 2004
> when this option was first added, the ld demangling support was
> deemed too experimental to make it the default, but that's surely not
> the case any more.  Also, since this has been broken since 2004, I'm
> not sure there's much reason to be concerned with backwards
> compatibility, here....
>
> (2) I fixed the COLLECT_NO_DEMANGLE environment variable setting
> recipe.
>
> (3) I simplified the argument processing for --demangle and
> --no-demangle to pass them straight through to the linker when
> HAVE_LD_DEMANGLE is defined.
>
> OK to commit?
>
> -Sandra
>
> 2011-06-17  Sandra Loosemore  <sandra@codesourcery.com>
>
>     gcc/
>     * configure.ac (demangler_in_ld): Default to yes.
>     * configure: Regenerated.
>     * collect2.c (main): When HAVE_LD_DEMANGLE is defined, don't
>     mess with COLLECT_NO_DEMANGLE, and just pass --demangle and
>     --no-demangle options straight through to ld.  When
>     HAVE_LD_DEMANGLE is not defined, set COLLECT_NO_DEMANGLE in a
>     way that has the intended effect on Windows.
>
>

Re: PING^2 Re: PATCH: fix collect2 handling of --demangle and --no-demangle

[Joseph S. Myers]

OK in the absence of middle-end or build-system maintainer objections 
within 72 hours.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: PING^2 Re: PATCH: fix collect2 handling of --demangle and --no-demangle

[H.J. Lu]

On Mon, Jul 11, 2011 at 10:45 AM, Sandra Loosemore
<sandra@codesourcery.com> wrote:
> Ping?
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01368.html
>
>> We had a bug report from a customer that the linker was ignoring the
>> --demangle and --no-demangle options when generating map files.
>> Moreover, it was failing in a host-dependent way; on Windows hosts,
>> it was always emitting demangled names in the map file, while on
>> Linux hosts, it never did.  Moreover, on Windows hosts it also
>> ignored the setting of the COLLECT_NO_DEMANGLE environment variable.
>>
>> This turns out to be a problem in collect2, or actually, three
>> problems:
>>
>> (1) By default, collect2 is configured to filter out --demangle and
>> --no-demangle from the linker options, and it tries to do demangling
>> on symbol names in stdout and stderr itself instead.  But, it is too
>> stupid to know about the map file.
>>
>> (2) Collect2 is trying to set COLLECT_NO_DEMANGLE to disable
>> demangling in ld, but in a nonportable way that causes it to be
>> always unset instead on Windows.
>>
>> (3) If you configure with --with-demangler-in-ld to try to disable
>> the collect2 demangling, there's another bug that causes it to ignore
>> any explicit --demangle or --no-demangle options and only pay
>> attention to whether or not COLLECT_NO_DEMANGLE is set.
>>
>> The attached patch addresses all three problems:
>>
>> (1) I've flipped the default to --with-demangler-in-ld=yes.  Note
>> that configure.ac already takes care not to let this percolate
>> through to collect2 without verifying that the linker is GNU ld and
>> that it is a version that supports --demangle.  Perhaps back in 2004
>> when this option was first added, the ld demangling support was
>> deemed too experimental to make it the default, but that's surely not
>> the case any more.  Also, since this has been broken since 2004, I'm
>> not sure there's much reason to be concerned with backwards
>> compatibility, here....
>>
>> (2) I fixed the COLLECT_NO_DEMANGLE environment variable setting
>> recipe.
>>
>> (3) I simplified the argument processing for --demangle and
>> --no-demangle to pass them straight through to the linker when
>> HAVE_LD_DEMANGLE is defined.
>>
>> OK to commit?
>>
>> -Sandra
>>
>> 2011-06-17  Sandra Loosemore  <sandra@codesourcery.com>
>>
>>    gcc/
>>    * configure.ac (demangler_in_ld): Default to yes.
>>    * configure: Regenerated.
>>    * collect2.c (main): When HAVE_LD_DEMANGLE is defined, don't
>>    mess with COLLECT_NO_DEMANGLE, and just pass --demangle and
>>    --no-demangle options straight through to ld.  When
>>    HAVE_LD_DEMANGLE is not defined, set COLLECT_NO_DEMANGLE in a
>>    way that has the intended effect on Windows.

It caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49835


-- 
H.J.

Re: PING^2 Re: PATCH: fix collect2 handling of --demangle and --no-demangle

[H.J. Lu]

On Sun, Jul 24, 2011 at 7:03 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jul 11, 2011 at 10:45 AM, Sandra Loosemore
> <sandra@codesourcery.com> wrote:
>> Ping?
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01368.html
>>
>>> We had a bug report from a customer that the linker was ignoring the
>>> --demangle and --no-demangle options when generating map files.
>>> Moreover, it was failing in a host-dependent way; on Windows hosts,
>>> it was always emitting demangled names in the map file, while on
>>> Linux hosts, it never did.  Moreover, on Windows hosts it also
>>> ignored the setting of the COLLECT_NO_DEMANGLE environment variable.
>>>
>>> This turns out to be a problem in collect2, or actually, three
>>> problems:
>>>
>>> (1) By default, collect2 is configured to filter out --demangle and
>>> --no-demangle from the linker options, and it tries to do demangling
>>> on symbol names in stdout and stderr itself instead.  But, it is too
>>> stupid to know about the map file.
>>>
>>> (2) Collect2 is trying to set COLLECT_NO_DEMANGLE to disable
>>> demangling in ld, but in a nonportable way that causes it to be
>>> always unset instead on Windows.
>>>
>>> (3) If you configure with --with-demangler-in-ld to try to disable
>>> the collect2 demangling, there's another bug that causes it to ignore
>>> any explicit --demangle or --no-demangle options and only pay
>>> attention to whether or not COLLECT_NO_DEMANGLE is set.
>>>
>>> The attached patch addresses all three problems:
>>>
>>> (1) I've flipped the default to --with-demangler-in-ld=yes.  Note
>>> that configure.ac already takes care not to let this percolate
>>> through to collect2 without verifying that the linker is GNU ld and
>>> that it is a version that supports --demangle.  Perhaps back in 2004
>>> when this option was first added, the ld demangling support was
>>> deemed too experimental to make it the default, but that's surely not
>>> the case any more.  Also, since this has been broken since 2004, I'm
>>> not sure there's much reason to be concerned with backwards
>>> compatibility, here....
>>>
>>> (2) I fixed the COLLECT_NO_DEMANGLE environment variable setting
>>> recipe.
>>>
>>> (3) I simplified the argument processing for --demangle and
>>> --no-demangle to pass them straight through to the linker when
>>> HAVE_LD_DEMANGLE is defined.
>>>
>>> OK to commit?
>>>
>>> -Sandra
>>>
>>> 2011-06-17  Sandra Loosemore  <sandra@codesourcery.com>
>>>
>>>    gcc/
>>>    * configure.ac (demangler_in_ld): Default to yes.
>>>    * configure: Regenerated.
>>>    * collect2.c (main): When HAVE_LD_DEMANGLE is defined, don't
>>>    mess with COLLECT_NO_DEMANGLE, and just pass --demangle and
>>>    --no-demangle options straight through to ld.  When
>>>    HAVE_LD_DEMANGLE is not defined, set COLLECT_NO_DEMANGLE in a
>>>    way that has the intended effect on Windows.
>
> It caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49835
>

I checked in this as an obvious fix.


-- 
H.J.
---
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 207b097..70cac5b 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2011-07-24  H.J. Lu  <hongjiu.lu@intel.com>
+
+	PR bootstrap/49835
+	* collect2.c (demangle_flag): Removed.
+
 2011-07-24  Sandra Loosemore  <sandra@codesourcery.com>

 	* configure.ac (demangler_in_ld): Default to yes.
diff --git a/gcc/collect2.c b/gcc/collect2.c
index cd0fad7..cf39693 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -179,7 +179,6 @@ struct head
 bool vflag;				/* true if -v or --version */
 static int rflag;			/* true if -r */
 static int strip_flag;			/* true if -s */
-static const char *demangle_flag;
 #ifdef COLLECT_EXPORT_LIST
 static int export_flag;                 /* true if -bE */
 static int aix64_flag;			/* true if -b64 */

Re: PING^2 Re: PATCH: fix collect2 handling of --demangle and --no-demangle

[Sandra Loosemore]

On 07/24/2011 08:09 PM, H.J. Lu wrote:
> On Sun, Jul 24, 2011 at 7:03 PM, H.J. Lu<hjl.tools@gmail.com>  wrote:
>> On Mon, Jul 11, 2011 at 10:45 AM, Sandra Loosemore
>> <sandra@codesourcery.com>  wrote:
>>>
>>>> 2011-06-17  Sandra Loosemore<sandra@codesourcery.com>
>>>>
>>>>     gcc/
>>>>     * configure.ac (demangler_in_ld): Default to yes.
>>>>     * configure: Regenerated.
>>>>     * collect2.c (main): When HAVE_LD_DEMANGLE is defined, don't
>>>>     mess with COLLECT_NO_DEMANGLE, and just pass --demangle and
>>>>     --no-demangle options straight through to ld.  When
>>>>     HAVE_LD_DEMANGLE is not defined, set COLLECT_NO_DEMANGLE in a
>>>>     way that has the intended effect on Windows.
>>
>> It caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49835
>
> I checked in this as an obvious fix.

Oops!  Sorry about that.  I thought I had fixed that problem.  :-(

-Sandra