version scripts and default/C language mangling

version scripts and default/C language mangling

[Mike Frysinger]

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

the current version script page does not define a default language:
	http://sourceware.org/binutils/docs/ld/VERSION.html
presumably it works with linker-visible symbols by default which means targets 
that have an ABI prefix (like the Blackfin port) wont usually match.

to speak in exact terms, if i compile the code on my x86_64 system:
	extern "C" int foo(void) {}
	extern "C" int var(void) {}
	int f(int x, double d) {}
i get an object with the linker visible symbols:
	foo
	bar
	_Z1fid

if i compile it with my Blackfin toolchain, i get:
	_foo
	_bar
	__Z1fid

using a version script of:
	{
		global:
			foo;
			extern "C" { bar; };
			extern "C++" { "f(int, double)"; };
		local: *;
	};

on x86_64, all the symbols will be GLOBAL.  on Blackfin, all will be LOCAL.  
i'm ok with "foo" being LOCAL, but it seems like the other two should be 
exported per the declared language.

at the moment, ldlang.c:lang_vers_match() doesnt do demangling for C symbols, 
and the cplus_demangle() doesnt account for the ABI prefix.  that is only 
declared via USER_LABEL_PREFIX in the emulparams subfolder, but it isnt 
exported to any C code that i can see.  not that we'd really want to since 
this is a bfd target specific issue.  any tips on how best to proceed here to 
fix things ?

also, i noticed the example script in the referenced URL above seems to have 
some errors in it.  it suggests:
	extern "C++" { "int f(int, double)"; }
but a C++ function like that doesnt encode the return type into the mangled 
name, so when the linker demangles things, it ends up with "f(int, double)" 
and so it never matches.  the example also lacks a trailing semicolon after 
the brace, so the linker complains about a syntax error in the file.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: version scripts and default/C language mangling

[Ian Lance Taylor]

Mike Frysinger <vapier@gentoo.org> writes:

> the current version script page does not define a default language:
> 	http://sourceware.org/binutils/docs/ld/VERSION.html
> presumably it works with linker-visible symbols by default which means targets 
> that have an ABI prefix (like the Blackfin port) wont usually match.

A leading underscore is normally returned by bfd_get_symbol_leading_char
on the BFD, which returns '\0' if there is no leading character.  I
think you are suggesting that the version script handling is not
checking for that.

> at the moment, ldlang.c:lang_vers_match() doesnt do demangling for C symbols, 
> and the cplus_demangle() doesnt account for the ABI prefix.  that is only 
> declared via USER_LABEL_PREFIX in the emulparams subfolder, but it isnt 
> exported to any C code that i can see.  not that we'd really want to since 
> this is a bfd target specific issue.  any tips on how best to proceed here to 
> fix things ?

USER_LABEL_PREFIX only affects the default linker script.  The relevant
code here is

#define elf_symbol_leading_char		'_'

in bfd/elf32-bfin.c.

Ian

Re: version scripts and default/C language mangling

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2056 bytes --]

On Sunday, July 11, 2010 07:56:56 Ian Lance Taylor wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > the current version script page does not define a default language:
> > 	http://sourceware.org/binutils/docs/ld/VERSION.html
> > 
> > presumably it works with linker-visible symbols by default which means
> > targets that have an ABI prefix (like the Blackfin port) wont usually
> > match.
> 
> A leading underscore is normally returned by bfd_get_symbol_leading_char
> on the BFD, which returns '\0' if there is no leading character.  I
> think you are suggesting that the version script handling is not
> checking for that.

first, i'm asking what the default language is for the version script.  i'd 
expect the answer to be "no language" which means the symbols would be matched 
against any random leading char a target introduces.  i'm also OK with the 
answer "C language", although it does prevent working with symbols that lack 
the prefix char because they were created via assembly code.

> > at the moment, ldlang.c:lang_vers_match() doesnt do demangling for C
> > symbols, and the cplus_demangle() doesnt account for the ABI prefix. 
> > that is only declared via USER_LABEL_PREFIX in the emulparams subfolder,
> > but it isnt exported to any C code that i can see.  not that we'd really
> > want to since this is a bfd target specific issue.  any tips on how best
> > to proceed here to fix things ?
> 
> USER_LABEL_PREFIX only affects the default linker script.  The relevant
> code here is
> 
> #define elf_symbol_leading_char		'_'
> 
> in bfd/elf32-bfin.c.

yes, but presumably changing ldlang.c to consider that value is unacceptable.  
the current parsing code is also not given the current bfd, only 
bfd_elf_version_expr structures, and those dont contain links back to a bfd 
that i can see.  unless there is a way to get the current "active" bfd ?  then 
it should be easy to drop in support in lang_vers_match() with the function 
bfd_get_symbol_leading_char() you pointed out.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: version scripts and default/C language mangling

[Ian Lance Taylor]

Mike Frysinger <vapier@gentoo.org> writes:

> first, i'm asking what the default language is for the version script.  i'd 
> expect the answer to be "no language" which means the symbols would be matched 
> against any random leading char a target introduces.  i'm also OK with the 
> answer "C language", although it does prevent working with symbols that lack 
> the prefix char because they were created via assembly code.

The default language is "C".  I think the right thing to do in that case
is strip the leading character if present, and otherwise do nothing.
That is what bfd_demangle does.


> yes, but presumably changing ldlang.c to consider that value is unacceptable.  
> the current parsing code is also not given the current bfd, only 
> bfd_elf_version_expr structures, and those dont contain links back to a bfd 
> that i can see.  unless there is a way to get the current "active" bfd ?  then 
> it should be easy to drop in support in lang_vers_match() with the function 
> bfd_get_symbol_leading_char() you pointed out.

I think it would be entirely reasonable to change lang_vers_match to
take a BFD parameter, and change the corresponding calling code in
bfd/elflink.c.  Or, the output BFD is always available in
link_info.output_bfd.

Ian

Re: version scripts and default/C language mangling

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 3740 bytes --]

On Monday, July 12, 2010 04:05:02 Ian Lance Taylor wrote:
> Mike Frysinger writes:
> > first, i'm asking what the default language is for the version script. 
> > i'd expect the answer to be "no language" which means the symbols would
> > be matched against any random leading char a target introduces.  i'm
> > also OK with the answer "C language", although it does prevent working
> > with symbols that lack the prefix char because they were created via
> > assembly code.
> 
> The default language is "C".  I think the right thing to do in that case
> is strip the leading character if present, and otherwise do nothing.
> That is what bfd_demangle does.

works for me

> > yes, but presumably changing ldlang.c to consider that value is
> > unacceptable. the current parsing code is also not given the current
> > bfd, only bfd_elf_version_expr structures, and those dont contain links
> > back to a bfd that i can see.  unless there is a way to get the current
> > "active" bfd ?  then it should be easy to drop in support in
> > lang_vers_match() with the function bfd_get_symbol_leading_char() you
> > pointed out.
> 
> I think it would be entirely reasonable to change lang_vers_match to
> take a BFD parameter, and change the corresponding calling code in
> bfd/elflink.c.  Or, the output BFD is always available in
> link_info.output_bfd.

since the existing bfd_demangle user in this file is using
link_info.output_bfd, i'm going to roll with that.

how does the attached patch look ?  seems to fix things with Blackfin targets,
and no regressions are seen with x86_64-linux-gnu and bfin-linux-uclibc.

i'll do some more system wide testing in the mean time ...
-mike

diff --git a/ld/ldlang.c b/ld/ldlang.c
index 9c4e17b..5875ef6 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -7179,19 +7179,28 @@ lang_vers_match (struct bfd_elf_version_expr_head *head,
 		 struct bfd_elf_version_expr *prev,
 		 const char *sym)
 {
+  const char *c_sym;
   const char *cxx_sym = sym;
   const char *java_sym = sym;
   struct bfd_elf_version_expr *expr = NULL;
+  enum demangling_styles curr_style;
+
+  curr_style = CURRENT_DEMANGLING_STYLE;
+  c_sym = bfd_demangle (link_info.output_bfd, sym, DMGL_NO_OPTS);
+  if (!c_sym)
+    c_sym = sym;
+  cplus_demangle_set_style (curr_style);
 
   if (head->mask & BFD_ELF_VERSION_CXX_TYPE)
     {
-      cxx_sym = cplus_demangle (sym, DMGL_PARAMS | DMGL_ANSI);
+      cxx_sym = bfd_demangle (link_info.output_bfd, sym,
+			      DMGL_PARAMS | DMGL_ANSI);
       if (!cxx_sym)
 	cxx_sym = sym;
     }
   if (head->mask & BFD_ELF_VERSION_JAVA_TYPE)
     {
-      java_sym = cplus_demangle (sym, DMGL_JAVA);
+      java_sym = bfd_demangle (link_info.output_bfd, sym, DMGL_JAVA);
       if (!java_sym)
 	java_sym = sym;
     }
@@ -7205,10 +7214,10 @@ lang_vers_match (struct bfd_elf_version_expr_head *head,
 	case 0:
 	  if (head->mask & BFD_ELF_VERSION_C_TYPE)
 	    {
-	      e.pattern = sym;
+	      e.pattern = c_sym;
 	      expr = (struct bfd_elf_version_expr *)
                   htab_find ((htab_t) head->htab, &e);
-	      while (expr && strcmp (expr->pattern, sym) == 0)
+	      while (expr && strcmp (expr->pattern, c_sym) == 0)
 		if (expr->mask == BFD_ELF_VERSION_C_TYPE)
 		  goto out_ret;
 		else
@@ -7266,12 +7275,14 @@ lang_vers_match (struct bfd_elf_version_expr_head *head,
       else if (expr->mask == BFD_ELF_VERSION_CXX_TYPE)
 	s = cxx_sym;
       else
-	s = sym;
+	s = c_sym;
       if (fnmatch (expr->pattern, s, 0) == 0)
 	break;
     }
 
  out_ret:
+  if (c_sym != sym)
+    free ((char *) c_sym);
   if (cxx_sym != sym)
     free ((char *) cxx_sym);
   if (java_sym != sym)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: version scripts and default/C language mangling

[Alan Modra]

On Mon, Jul 19, 2010 at 07:31:01PM -0400, Mike Frysinger wrote:
> how does the attached patch look ?  seems to fix things with Blackfin targets,
> and no regressions are seen with x86_64-linux-gnu and bfin-linux-uclibc.

I like it.  Should allow me to get rid of ppc64elf.em:new_vers_pattern
if I'm not mistaken.

-- 
Alan Modra
Australia Development Lab, IBM

Re: version scripts and default/C language mangling

[Will Newton]

On Tue, Jul 20, 2010 at 12:31 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday, July 12, 2010 04:05:02 Ian Lance Taylor wrote:
>> Mike Frysinger writes:
>> > first, i'm asking what the default language is for the version script.
>> > i'd expect the answer to be "no language" which means the symbols would
>> > be matched against any random leading char a target introduces.  i'm
>> > also OK with the answer "C language", although it does prevent working
>> > with symbols that lack the prefix char because they were created via
>> > assembly code.
>>
>> The default language is "C".  I think the right thing to do in that case
>> is strip the leading character if present, and otherwise do nothing.
>> That is what bfd_demangle does.
>
> works for me
>
>> > yes, but presumably changing ldlang.c to consider that value is
>> > unacceptable. the current parsing code is also not given the current
>> > bfd, only bfd_elf_version_expr structures, and those dont contain links
>> > back to a bfd that i can see.  unless there is a way to get the current
>> > "active" bfd ?  then it should be easy to drop in support in
>> > lang_vers_match() with the function bfd_get_symbol_leading_char() you
>> > pointed out.
>>
>> I think it would be entirely reasonable to change lang_vers_match to
>> take a BFD parameter, and change the corresponding calling code in
>> bfd/elflink.c.  Or, the output BFD is always available in
>> link_info.output_bfd.
>
> since the existing bfd_demangle user in this file is using
> link_info.output_bfd, i'm going to roll with that.
>
> how does the attached patch look ?  seems to fix things with Blackfin targets,
> and no regressions are seen with x86_64-linux-gnu and bfin-linux-uclibc.
>
> i'll do some more system wide testing in the mean time ...

Hi Mike,

Did this patch pass your testing?

I would be interested in trying it out but it would appear that the
patch you sent has been mangled by Exchange (= characters everywhere).

Cheers,

Re: version scripts and default/C language mangling

[Mike Frysinger]

On Tue, Aug 17, 2010 at 6:15 AM, Will Newton wrote:
> On Tue, Jul 20, 2010 at 12:31 AM, Mike Frysinger wrote:
>> On Monday, July 12, 2010 04:05:02 Ian Lance Taylor wrote:
>>> Mike Frysinger writes:
>>> > first, i'm asking what the default language is for the version script.
>>> > i'd expect the answer to be "no language" which means the symbols would
>>> > be matched against any random leading char a target introduces.  i'm
>>> > also OK with the answer "C language", although it does prevent working
>>> > with symbols that lack the prefix char because they were created via
>>> > assembly code.
>>>
>>> The default language is "C".  I think the right thing to do in that case
>>> is strip the leading character if present, and otherwise do nothing.
>>> That is what bfd_demangle does.
>>
>> works for me
>>
>>> > yes, but presumably changing ldlang.c to consider that value is
>>> > unacceptable. the current parsing code is also not given the current
>>> > bfd, only bfd_elf_version_expr structures, and those dont contain links
>>> > back to a bfd that i can see.  unless there is a way to get the current
>>> > "active" bfd ?  then it should be easy to drop in support in
>>> > lang_vers_match() with the function bfd_get_symbol_leading_char() you
>>> > pointed out.
>>>
>>> I think it would be entirely reasonable to change lang_vers_match to
>>> take a BFD parameter, and change the corresponding calling code in
>>> bfd/elflink.c.  Or, the output BFD is always available in
>>> link_info.output_bfd.
>>
>> since the existing bfd_demangle user in this file is using
>> link_info.output_bfd, i'm going to roll with that.
>>
>> how does the attached patch look ?  seems to fix things with Blackfin targets,
>> and no regressions are seen with x86_64-linux-gnu and bfin-linux-uclibc.
>>
>> i'll do some more system wide testing in the mean time ...
>
> Did this patch pass your testing?

the patch i posted needed one minor fix, but other than that, it seems
to be working properly for me
-mike

[PATCH] bfd/ld: handle ABI prefixes in version scripts

[Mike Frysinger]

The default language in version scripts is supposed to be C, but no
symbol demangling is performed on the symbols by default.  This makes
targets with a symbol prefix to fail with most version scripts out
there.  So strip away this prefix by default.

This fixes many tests (real world and ld's testsuite) for Blackfin
targets and doesn't seem to cause regressions for x86_64.

I was holding off on this once binutils-2.21 was done, and we've
hit that point now.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

bfd/:
2010-12-09  Mike Frysinger  <vapier@gentoo.org>

	* elflink.c (bfd_elf_size_dynamic_sections): Add
	bfd_get_symbol_leading_char to the start of newname.

ld/:
2010-12-09  Mike Frysinger  <vapier@gentoo.org>

	* ldlang.c (lang_vers_match): Declare a new c_sym, assign it to
	the bfd_demangle of sym, change users of sym to c_sym when not
	already demangling, and free when done.  Change callers of
	cplus_demangle to bfd_demangle.
---
 bfd/elflink.c |    8 +++++---
 ld/ldlang.c   |   22 +++++++++++++++++-----
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/bfd/elflink.c b/bfd/elflink.c
index 32575d9..52b2afe 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -5713,11 +5713,12 @@ bfd_elf_size_dynamic_sections (bfd *output_bfd,
 	    {
 	      const char *verstr, *name;
 	      size_t namelen, verlen, newlen;
-	      char *newname, *p;
+	      char *newname, *p, leading_char;
 	      struct elf_link_hash_entry *newh;
 
+	      leading_char = bfd_get_symbol_leading_char (output_bfd);
 	      name = d->pattern;
-	      namelen = strlen (name);
+	      namelen = strlen (name) + (leading_char != '\0');
 	      verstr = t->name;
 	      verlen = strlen (verstr);
 	      newlen = namelen + verlen + 3;
@@ -5725,7 +5726,8 @@ bfd_elf_size_dynamic_sections (bfd *output_bfd,
 	      newname = (char *) bfd_malloc (newlen);
 	      if (newname == NULL)
 		return FALSE;
-	      memcpy (newname, name, namelen);
+	      newname[0] = leading_char;
+	      memcpy (newname + (leading_char != '\0'), name, namelen);
 
 	      /* Check the hidden versioned definition.  */
 	      p = newname + namelen;
diff --git a/ld/ldlang.c b/ld/ldlang.c
index e804a53..28d2756 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -7299,19 +7299,29 @@ lang_vers_match (struct bfd_elf_version_expr_head *head,
 		 struct bfd_elf_version_expr *prev,
 		 const char *sym)
 {
+  const char *c_sym;
   const char *cxx_sym = sym;
   const char *java_sym = sym;
   struct bfd_elf_version_expr *expr = NULL;
+  enum demangling_styles curr_style;
+
+  curr_style = CURRENT_DEMANGLING_STYLE;
+  cplus_demangle_set_style (no_demangling);
+  c_sym = bfd_demangle (link_info.output_bfd, sym, DMGL_NO_OPTS);
+  if (!c_sym)
+    c_sym = sym;
+  cplus_demangle_set_style (curr_style);
 
   if (head->mask & BFD_ELF_VERSION_CXX_TYPE)
     {
-      cxx_sym = cplus_demangle (sym, DMGL_PARAMS | DMGL_ANSI);
+      cxx_sym = bfd_demangle (link_info.output_bfd, sym,
+			      DMGL_PARAMS | DMGL_ANSI);
       if (!cxx_sym)
 	cxx_sym = sym;
     }
   if (head->mask & BFD_ELF_VERSION_JAVA_TYPE)
     {
-      java_sym = cplus_demangle (sym, DMGL_JAVA);
+      java_sym = bfd_demangle (link_info.output_bfd, sym, DMGL_JAVA);
       if (!java_sym)
 	java_sym = sym;
     }
@@ -7325,10 +7335,10 @@ lang_vers_match (struct bfd_elf_version_expr_head *head,
 	case 0:
 	  if (head->mask & BFD_ELF_VERSION_C_TYPE)
 	    {
-	      e.pattern = sym;
+	      e.pattern = c_sym;
 	      expr = (struct bfd_elf_version_expr *)
                   htab_find ((htab_t) head->htab, &e);
-	      while (expr && strcmp (expr->pattern, sym) == 0)
+	      while (expr && strcmp (expr->pattern, c_sym) == 0)
 		if (expr->mask == BFD_ELF_VERSION_C_TYPE)
 		  goto out_ret;
 		else
@@ -7386,12 +7396,14 @@ lang_vers_match (struct bfd_elf_version_expr_head *head,
       else if (expr->mask == BFD_ELF_VERSION_CXX_TYPE)
 	s = cxx_sym;
       else
-	s = sym;
+	s = c_sym;
       if (fnmatch (expr->pattern, s, 0) == 0)
 	break;
     }
 
  out_ret:
+  if (c_sym != sym)
+    free ((char *) c_sym);
   if (cxx_sym != sym)
     free ((char *) cxx_sym);
   if (java_sym != sym)
-- 
1.7.3.1

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Joseph S. Myers]

On Thu, 9 Dec 2010, Mike Frysinger wrote:

> The default language in version scripts is supposed to be C, but no
> symbol demangling is performed on the symbols by default.  This makes
> targets with a symbol prefix to fail with most version scripts out
> there.  So strip away this prefix by default.
> 
> This fixes many tests (real world and ld's testsuite) for Blackfin
> targets and doesn't seem to cause regressions for x86_64.

Blackfin has its own libgcc version script in GCC that duplicates the 
standard script precisely because of the leading underscores.  (The script 
also has two Blackfin-specific symbols, and is missing symbols added for 
GCC 4.6.  The latter illustrates the problem with having this script.)  
So it would seem you need to coordinate this change in some way with GCC, 
if I understand it correctly - possibly making GCC 4.6 for Blackfin 
require a new linker and replacing the duplicate version script with one 
just defining the two Blackfin-specific symbols.  That doesn't solve the 
problem with old GCC and new linkers, though you could add a configure 
test to 4.3/4.4/4.5 release branches to reject new linkers for Blackfin.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1400 bytes --]

On Thursday, December 09, 2010 16:42:59 Joseph S. Myers wrote:
> On Thu, 9 Dec 2010, Mike Frysinger wrote:
> > The default language in version scripts is supposed to be C, but no
> > symbol demangling is performed on the symbols by default.  This makes
> > targets with a symbol prefix to fail with most version scripts out
> > there.  So strip away this prefix by default.
> > 
> > This fixes many tests (real world and ld's testsuite) for Blackfin
> > targets and doesn't seem to cause regressions for x86_64.
> 
> Blackfin has its own libgcc version script in GCC that duplicates the
> standard script precisely because of the leading underscores.

yes, i already have a patch in our local gcc copy to move Blackfin to the 
standard and drop most of our local changes.  but i need the linker working 
before i can push that.

> So it would seem you need to coordinate this change in some way with GCC,
> if I understand it correctly - possibly making GCC 4.6 for Blackfin
> require a new linker and replacing the duplicate version script with one
> just defining the two Blackfin-specific symbols.  That doesn't solve the
> problem with old GCC and new linkers, though you could add a configure
> test to 4.3/4.4/4.5 release branches to reject new linkers for Blackfin.

are there any examples of binutils version checking that i can look at basing 
the work on ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Joseph S. Myers]

On Thu, 9 Dec 2010, Mike Frysinger wrote:

> > So it would seem you need to coordinate this change in some way with GCC,
> > if I understand it correctly - possibly making GCC 4.6 for Blackfin
> > require a new linker and replacing the duplicate version script with one
> > just defining the two Blackfin-specific symbols.  That doesn't solve the
> > problem with old GCC and new linkers, though you could add a configure
> > test to 4.3/4.4/4.5 release branches to reject new linkers for Blackfin.
> 
> are there any examples of binutils version checking that i can look at basing 
> the work on ?

There are lots of assembler checks that deal with various combinations of 
checking a version number (possibly for a unified tree build) and checking 
for features; see gcc_GAS_CHECK_FEATURE.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1198 bytes --]

On Friday, December 10, 2010 05:43:47 Joseph S. Myers wrote:
> On Thu, 9 Dec 2010, Mike Frysinger wrote:
> > > So it would seem you need to coordinate this change in some way with
> > > GCC, if I understand it correctly - possibly making GCC 4.6 for
> > > Blackfin require a new linker and replacing the duplicate version
> > > script with one just defining the two Blackfin-specific symbols.  That
> > > doesn't solve the problem with old GCC and new linkers, though you
> > > could add a configure test to 4.3/4.4/4.5 release branches to reject
> > > new linkers for Blackfin.
> > 
> > are there any examples of binutils version checking that i can look at
> > basing the work on ?
> 
> There are lots of assembler checks that deal with various combinations of
> checking a version number (possibly for a unified tree build) and checking
> for features; see gcc_GAS_CHECK_FEATURE.

seems like gcc_GAS_VERSION_GTE_IFELSE should do what i want.  these checks ok 
to put into gcc/config.gcc ?  that's where all the blackfin-specific logic is 
found currently, but doesnt seem like any other targets run any sort of tests 
in that file -- they seem to be in configure.ac.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1911 bytes --]

On Friday, December 10, 2010 18:03:52 Mike Frysinger wrote:
> On Friday, December 10, 2010 05:43:47 Joseph S. Myers wrote:
> > On Thu, 9 Dec 2010, Mike Frysinger wrote:
> > > > So it would seem you need to coordinate this change in some way with
> > > > GCC, if I understand it correctly - possibly making GCC 4.6 for
> > > > Blackfin require a new linker and replacing the duplicate version
> > > > script with one just defining the two Blackfin-specific symbols. 
> > > > That doesn't solve the problem with old GCC and new linkers, though
> > > > you could add a configure test to 4.3/4.4/4.5 release branches to
> > > > reject new linkers for Blackfin.
> > > 
> > > are there any examples of binutils version checking that i can look at
> > > basing the work on ?
> > 
> > There are lots of assembler checks that deal with various combinations of
> > checking a version number (possibly for a unified tree build) and
> > checking for features; see gcc_GAS_CHECK_FEATURE.
> 
> seems like gcc_GAS_VERSION_GTE_IFELSE should do what i want.  these checks
> ok to put into gcc/config.gcc ?  that's where all the blackfin-specific
> logic is found currently, but doesnt seem like any other targets run any
> sort of tests in that file -- they seem to be in configure.ac.

i found the right place in configure.ac (there's a "target specific checks" 
section), but i dont think these gas m4 macros are useful.  the version 
checking only works when the gas used is in tree, and this functionality cant 
be detected at the assembler level.  my fixes are only at the linker level, 
but there doesnt appear to be any linker helper checks that i can see.  so i'd 
have to do a link test with a custom version script (and hardcoded -Wl flags), 
and then do a review of the output (via readelf or nm).  which makes me think 
adding a configure test isnt really worth all the effort.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Joseph S. Myers]

On Mon, 13 Dec 2010, Mike Frysinger wrote:

> i found the right place in configure.ac (there's a "target specific checks" 
> section), but i dont think these gas m4 macros are useful.  the version 
> checking only works when the gas used is in tree, and this functionality cant 
> be detected at the assembler level.  my fixes are only at the linker level, 

Yes, it was an example of the sort of test that exists for binutils 
features and/or versions rather than something that can be directly used 
as-is.

gcc/configure.ac already contains code that computes a linker version 
number (gcc_cv_gld_major_version and gcc_cv_gld_minor_version).  There is 
also code (e.g. in libstdc++-v3/acinclude.m4) to compute a version of an 
out-of-tree linker (in fact, I think there are rather too many copies of 
such code in different directories that could do with some unification).  
So if you want to test version numbers without any feature tests, there 
should be various existing code to adapt.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 3148 bytes --]

On Monday, December 13, 2010 17:18:02 Joseph S. Myers wrote:
> On Mon, 13 Dec 2010, Mike Frysinger wrote:
> > i found the right place in configure.ac (there's a "target specific
> > checks" section), but i dont think these gas m4 macros are useful.  the
> > version checking only works when the gas used is in tree, and this
> > functionality cant be detected at the assembler level.  my fixes are
> > only at the linker level,
> 
> Yes, it was an example of the sort of test that exists for binutils
> features and/or versions rather than something that can be directly used
> as-is.
> 
> gcc/configure.ac already contains code that computes a linker version
> number (gcc_cv_gld_major_version and gcc_cv_gld_minor_version).  There is
> also code (e.g. in libstdc++-v3/acinclude.m4) to compute a version of an
> out-of-tree linker (in fact, I think there are rather too many copies of
> such code in different directories that could do with some unification).
> So if you want to test version numbers without any feature tests, there
> should be various existing code to adapt.

thanks.  this patch should do what i need.
-mike

--- a/gcc-4.3/gcc/acinclude.m4
+++ b/gcc-4.3/gcc/acinclude.m4
@@ -424,6 +424,19 @@ AC_DEFUN([gcc_GAS_VERSION_GTE_IFELSE],
 ifelse([$1], elf, [_gcc_GAS_VERSION_GTE_IFELSE($@)],
                   [_gcc_GAS_VERSION_GTE_IFELSE(,$@)])])
 
+dnl # gcc_GLD_VERSION_GTE_IFELSE(major, minor, [command_if_true = :],
+dnl #                            [command_if_false = :])
+dnl # Check to see if the version of GLD is greater than or
+dnl # equal to the specified version.
+AC_DEFUN([gcc_GLD_VERSION_GTE_IFELSE],
+[if test "$gcc_cv_gld_major_version" -eq $1 -a "$gcc_cv_gld_minor_version" -ge $2 \
+	 -o "$gcc_cv_gld_major_version" -gt $1
+ then dnl
+ifelse([$3],,:,[$3])[]dnl
+ifelse([$4],,,[
+  else $4])
+fi])
+
 dnl gcc_GAS_CHECK_FEATURE(description, cv, [[elf,]major,minor,patchlevel],
 dnl [extra switches to as], [assembler input],
 dnl [extra testing logic], [command if feature available])
--- a/gcc-4.3/gcc/configure.ac
+++ b/gcc-4.3/gcc/configure.ac
@@ -1970,6 +1970,14 @@ changequote(,)dnl
 	gcc_cv_gld_minor_version=`expr "$gcc_cv_gld_version" : "VERSION=[0-9]*\.\([0-9]*\)"`
 changequote([,])dnl
 else
+	if test x"$gnu_ld_flag" = x"yes" -o x"$with_gnu_ld" = x"yes"; then
+		changequote(,)
+		ldver=`$LD --version 2>/dev/null | head -1 | \
+		       sed -e 's/GNU ld \(version \)\{0,1\}\(([^)]*) \)\{0,1\}\([0-9.][0-9.]*\).*/\3/'`
+		changequote([,])
+		gcc_cv_gld_major_version=`echo $ldver | $AWK -F. '{print $1}'`
+		gcc_cv_gld_minor_version=`echo $ldver | $AWK -F. '{print $2}'`
+	fi
 	AC_MSG_RESULT($gcc_cv_ld)
 	in_tree_ld=no
 fi
@@ -3051,6 +3059,14 @@ x:
     ;;
 esac
 
+# Newer linker changed behavior with version scripts and symbol prefixes
+case "$target" in
+  bfin*-linux-uclibc*)
+    gcc_GLD_VERSION_GTE_IFELSE(2, 22, [:],
+      [AC_MSG_ERROR([GNU binutils 2.22+ needed for version script changes])])
+    ;;
+esac
+
 # Mips and HP-UX need the GNU assembler.
 # Linux on IA64 might be able to use the Intel assembler.
 

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 715 bytes --]

On Thursday, December 09, 2010 15:56:28 Mike Frysinger wrote:
> The default language in version scripts is supposed to be C, but no
> symbol demangling is performed on the symbols by default.  This makes
> targets with a symbol prefix to fail with most version scripts out
> there.  So strip away this prefix by default.
> 
> This fixes many tests (real world and ld's testsuite) for Blackfin
> targets and doesn't seem to cause regressions for x86_64.
> 
> I was holding off on this once binutils-2.21 was done, and we've
> hit that point now.

any feedback on this ?  in the older thread, people seemed to be ok with this 
(and at least one person was looking forward to this functionality).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 820 bytes --]

On Thursday, January 13, 2011 19:33:28 Mike Frysinger wrote:
> On Thursday, December 09, 2010 15:56:28 Mike Frysinger wrote:
> > The default language in version scripts is supposed to be C, but no
> > symbol demangling is performed on the symbols by default.  This makes
> > targets with a symbol prefix to fail with most version scripts out
> > there.  So strip away this prefix by default.
> > 
> > This fixes many tests (real world and ld's testsuite) for Blackfin
> > targets and doesn't seem to cause regressions for x86_64.
> > 
> > I was holding off on this once binutils-2.21 was done, and we've
> > hit that point now.
> 
> any feedback on this ?  in the older thread, people seemed to be ok with
> this (and at least one person was looking forward to this functionality).

no love ? :/
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Alan Modra]

On Thu, Dec 09, 2010 at 03:56:28PM -0500, Mike Frysinger wrote:
> bfd/:
> 2010-12-09  Mike Frysinger  <vapier@gentoo.org>
> 
> 	* elflink.c (bfd_elf_size_dynamic_sections): Add
> 	bfd_get_symbol_leading_char to the start of newname.
> 
> ld/:
> 2010-12-09  Mike Frysinger  <vapier@gentoo.org>
> 
> 	* ldlang.c (lang_vers_match): Declare a new c_sym, assign it to
> 	the bfd_demangle of sym, change users of sym to c_sym when not
> 	already demangling, and free when done.  Change callers of
> 	cplus_demangle to bfd_demangle.

OK.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH] bfd/ld: handle ABI prefixes in version scripts

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 668 bytes --]

On Monday, February 14, 2011 01:07:10 Alan Modra wrote:
> On Thu, Dec 09, 2010 at 03:56:28PM -0500, Mike Frysinger wrote:
> > bfd/:
> > 2010-12-09  Mike Frysinger  <vapier@gentoo.org>
> > 
> > 	* elflink.c (bfd_elf_size_dynamic_sections): Add
> > 	bfd_get_symbol_leading_char to the start of newname.
> > 
> > ld/:
> > 2010-12-09  Mike Frysinger  <vapier@gentoo.org>
> > 
> > 	* ldlang.c (lang_vers_match): Declare a new c_sym, assign it to
> > 	the bfd_demangle of sym, change users of sym to c_sym when not
> > 	already demangling, and free when done.  Change callers of
> > 	cplus_demangle to bfd_demangle.
> 
> OK.

thanks ... merged now
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]