[Patch/pe-i386]: ld/deffilep.y parsing of C++ mangled names with '.'

[Patch/pe-i386]: ld/deffilep.y parsing of C++ mangled names with '.'

[Danny Smith]

 G++'s mangling of names in unnamed namespaces causes a segmentation fault in
ld when
building pe-i386 shared libraries (dlls).

Compiling this with g++

// Filename.cc
namespace
{
  int iii;
};

emits the symbol name __ZN28_GLOBAL__N_Filename.cc1bK1ib3iiiE

I don't why anybody would want to explicitly export a name that is
declared in an unnamed namespace, but g+ -shared does it by default, when
 --export-all is implied by lack of explicit dllimport attributes or def file.

ld/deffilep.y does not handle the '.' in the name generated from the source
filename and results in a call to strlen with an NULL argument while trying to
report an invalid name.

The simplest fix I could come up with is to just accept '.' as a valid
non-lead char when parsing names:

ld/Changelog

2003-03-09  Danny Smith  <dannysmith@users.sourceforeg.net>

	* deffilep.y (def_lec): Accept '.' as valid non-lead char..


Index: deffilep.y
===================================================================
RCS file: /cvs/src/src/ld/deffilep.y,v
retrieving revision 1.11
diff -c -3 -p -r1.11 deffilep.y
*** deffilep.y	28 Jan 2003 11:39:43 -0000	1.11
--- deffilep.y	8 Mar 2003 06:26:34 -0000
*************** def_lex ()
*** 1020,1026 ****
  #endif
  	}
  
!       while (c != EOF && (ISALNUM (c) || strchr ("$:-_?/@", c)))
  	{
  	  put_buf (c);
  	  c = def_getc ();
--- 1020,1026 ----
  #endif
  	}
  
!       while (c != EOF && (ISALNUM (c) || strchr ("$:-_?/@.", c)))
  	{
  	  put_buf (c);
  	  c = def_getc ();  





However, I admit that I not know enough about how this will affect parsing
of LIBRARY or NAME commands. With this patch, the special treatment of '.'
in opt_name appears to be redundant. 

My tests with LIBRARY  or NAME commands in def files for windows targets
have succeeded with this patch.  What am I missing?   

Danny 

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

Re: [Patch/pe-i386]: ld/deffilep.y parsing of C++ mangled names with '.'

[Christopher Faylor]

On Sat, Mar 08, 2003 at 07:50:33PM +1100, Danny Smith wrote:
> G++'s mangling of names in unnamed namespaces causes a segmentation fault in
>ld when
>building pe-i386 shared libraries (dlls).
>
>Compiling this with g++
>
>// Filename.cc
>namespace
>{
>  int iii;
>};
>
>emits the symbol name __ZN28_GLOBAL__N_Filename.cc1bK1ib3iiiE
>
>I don't why anybody would want to explicitly export a name that is
>declared in an unnamed namespace, but g+ -shared does it by default, when
> --export-all is implied by lack of explicit dllimport attributes or def file.
>
>ld/deffilep.y does not handle the '.' in the name generated from the source
>filename and results in a call to strlen with an NULL argument while trying to
>report an invalid name.
>
>The simplest fix I could come up with is to just accept '.' as a valid
>non-lead char when parsing names:
>
>ld/Changelog
>
>2003-03-09  Danny Smith  <dannysmith@users.sourceforeg.net>
>
>	* deffilep.y (def_lec): Accept '.' as valid non-lead char..

Danny, go ahead and check this in.  It seems ok to me.

cgf