Commit Message

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.

Comments

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

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