Re: Blackfin and version scripts
On Tuesday, July 06, 2010 13:08:26 Mike Frysinger wrote: On Tuesday, July 06, 2010 12:34:13 Kurt Roeckx wrote: But my point is that a version script is nothing arch specific, unlike a linker script. Version scripts even support saying in which language the symbol is, so that it can properly mangle it for you. Adding the symbol inside an 'extern C' also doesn't have any effect. with no lang spec, it is arch specific because it is dealing in linker visible symbols. you are correct that 'extern C' should work though. after talking with the binutils guys, they seem to agree with you about the default language is C and not linker visible. so i'll pursue that course. thanks for the push. -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Mon, Jul 05, 2010 at 04:08:47PM -0400, Mike Frysinger wrote:
On Mon, Jul 5, 2010 at 12:50, Kurt Roeckx wrote:
On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote:
On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote:
On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote:
Hi!
GCRYPT_1.2 {
global:
gcry_check_version; gcry_control;
[...]
Blackfin seems to be the only platform which has version script support
and prefixes symbols with underscores. That does not work of course.
blackfins is one of the arches that defined underscores in the
ABI. But I don't think an application writer should care about
that, and that this is a bug in binutils.
no, it isnt. please read the whole thread and the linker documentation.
I'm not sure which part of the thread you think I missed that said
anything about it. Most of it is actually about complelty
unrelated issues that have nothing to do with bfin.
The only mail that seems to be about it is Ralf's mail about the
mangling. But I'm not convinced that libtool should do any
mangle/demangle thing. Atleast the gnu linker will already do the
proper thing for you, but some others might not.
If you think I missed something, please point me to the actual
mail or documentation.
you stated it is a bug in binutils. that is simply wrong. the
linker script deals in *linker visible* symbols while C code deals in
*C visible*. it has always been this way and as you indirectly
stated, this is not Blackfin specific.
We're talking about a version script, not a linker script.
But my point is that a version script is nothing arch specific,
unlike a linker script. Version scripts even support saying in
which language the symbol is, so that it can properly mangle it
for you. Adding the symbol inside an 'extern C' also doesn't
have any effect.
If you use a debugger, you also want to use break main, and that
actually works, even if the symbol is really called _main in the
file. You don't want to do break _main just because the
platform's ABI says that's the way symbols are named.
Kurt
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Tuesday, July 06, 2010 12:34:13 Kurt Roeckx wrote:
On Mon, Jul 05, 2010 at 04:08:47PM -0400, Mike Frysinger wrote:
On Mon, Jul 5, 2010 at 12:50, Kurt Roeckx wrote:
On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote:
On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote:
On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote:
Hi!
GCRYPT_1.2 {
global:
gcry_check_version; gcry_control;
[...]
Blackfin seems to be the only platform which has version script
support and prefixes symbols with underscores. That does not
work of course.
blackfins is one of the arches that defined underscores in the
ABI. But I don't think an application writer should care about
that, and that this is a bug in binutils.
no, it isnt. please read the whole thread and the linker
documentation.
I'm not sure which part of the thread you think I missed that said
anything about it. Most of it is actually about complelty
unrelated issues that have nothing to do with bfin.
The only mail that seems to be about it is Ralf's mail about the
mangling. But I'm not convinced that libtool should do any
mangle/demangle thing. Atleast the gnu linker will already do the
proper thing for you, but some others might not.
If you think I missed something, please point me to the actual
mail or documentation.
you stated it is a bug in binutils. that is simply wrong. the
linker script deals in *linker visible* symbols while C code deals in
*C visible*. it has always been this way and as you indirectly
stated, this is not Blackfin specific.
We're talking about a version script, not a linker script.
typo; i meant version script
But my point is that a version script is nothing arch specific,
unlike a linker script. Version scripts even support saying in
which language the symbol is, so that it can properly mangle it
for you. Adding the symbol inside an 'extern C' also doesn't
have any effect.
with no lang spec, it is arch specific because it is dealing in linker visible
symbols. you are correct that 'extern C' should work though.
-mike
signature.asc
Description: This is a digitally signed message part.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote:
On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote:
Hi!
GCRYPT_1.2 {
global:
gcry_check_version; gcry_control;
[...]
Blackfin seems to be the only platform which has version script support
and prefixes symbols with underscores. That does not work of course.
blackfins is one of the arches that defined underscores in the
ABI. But I don't think an application writer should care about
that, and that this is a bug in binutils.
no, it isnt. please read the whole thread and the linker documentation.
-mike
signature.asc
Description: This is a digitally signed message part.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote:
On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote:
On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote:
Hi!
GCRYPT_1.2 {
global:
gcry_check_version; gcry_control;
[...]
Blackfin seems to be the only platform which has version script support
and prefixes symbols with underscores. That does not work of course.
blackfins is one of the arches that defined underscores in the
ABI. But I don't think an application writer should care about
that, and that this is a bug in binutils.
no, it isnt. please read the whole thread and the linker documentation.
I'm not sure which part of the thread you think I missed that said
anything about it. Most of it is actually about complelty
unrelated issues that have nothing to do with bfin.
The only mail that seems to be about it is Ralf's mail about the
mangling. But I'm not convinced that libtool should do any
mangle/demangle thing. Atleast the gnu linker will already do the
proper thing for you, but some others might not.
If you think I missed something, please point me to the actual
mail or documentation.
Kurt
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Mon, Jul 5, 2010 at 12:50, Kurt Roeckx wrote:
On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote:
On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote:
On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote:
Hi!
GCRYPT_1.2 {
global:
gcry_check_version; gcry_control;
[...]
Blackfin seems to be the only platform which has version script support
and prefixes symbols with underscores. That does not work of course.
blackfins is one of the arches that defined underscores in the
ABI. But I don't think an application writer should care about
that, and that this is a bug in binutils.
no, it isnt. please read the whole thread and the linker documentation.
I'm not sure which part of the thread you think I missed that said
anything about it. Most of it is actually about complelty
unrelated issues that have nothing to do with bfin.
The only mail that seems to be about it is Ralf's mail about the
mangling. But I'm not convinced that libtool should do any
mangle/demangle thing. Atleast the gnu linker will already do the
proper thing for you, but some others might not.
If you think I missed something, please point me to the actual
mail or documentation.
you stated it is a bug in binutils. that is simply wrong. the
linker script deals in *linker visible* symbols while C code deals in
*C visible*. it has always been this way and as you indirectly
stated, this is not Blackfin specific.
-mike
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote:
Hi!
GCRYPT_1.2 {
global:
gcry_check_version; gcry_control;
[...]
Blackfin seems to be the only platform which has version script support
and prefixes symbols with underscores. That does not work of course.
blackfins is one of the arches that defined underscores in the
ABI. But I don't think an application writer should care about
that, and that this is a bug in binutils.
Kurt
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
Hello Werner, all, * Werner Koch wrote on Tue, Jun 22, 2010 at 11:42:43AM CEST: Mike and Robin found a build problem with libgcrypt on Blackfin using the GNU toolchain: Libgcrypt as most other GnuPG related libraries tries to keep a well defined ABI and thus use a version script to guarantee that. The version script is passed to libtool this way: if HAVE_LD_VERSION_SCRIPT libgcrypt_version_script_cmd = -Wl,--version-script=$(srcdir)/libgcrypt.vers else libgcrypt_version_script_cmd = endif [...] libgcrypt_la_LDFLAGS = $(no_undefined) $(export_symbols) \ $(libgcrypt_version_script_cmd) -version-info \ @LIBGCRYPT_LT_CURRENT@:@LIBGCRYPT_LT_REVISION@:@LIBGCRYPT_LT_AGE@ $(no_undefined) $(export_symbols) are only used for W32 and not defined if we have version script support. Why is -no-undefined not used unconditionally? For C-only code, this shouldn't be a problem (and if it is, we'd like to hear about it). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
* Werner Koch wrote on Wed, Jun 23, 2010 at 09:46:01AM CEST:
On Wed, 23 Jun 2010 07:29, r...@stanford.edu said:
I can take a pass at starting. All that I need for my packages is to
support the basic version syntax:
version {
global:
symbol;
That would be sufficient for me too as long as a version_2 with only
global symbols is supported as well.
Having a second file with a simple list of symbols instead of a version
script parser is another option. Actually this is required because to
support W32 we need a .def file
EXPORTS
gcry_check_version @1
gcry_control @2
which allows to assign id numbers to symbols. In theory we could add
this via comment lines to a versions script but that would make a parser
even more complicated. In some projects I create the .def file from a
.def.in file to handle differences between W32 and W32CE. In any case
the .def file is easy to parse and could be used as input to
--export-symbols.
OK, so the problem space as I see it:
- complex GNU/Solaris ld version scripts, but most users need only a
fairly simple part of that,
- w32 .def files,
- symbols lists or regexes as used by libtool,
- the wild card specification to use: ld uses globbing,
-export-symbols-regex uses ERE.
- mangling relevant also for C: prepending underscore or not, appending
calling convention suffixes @... on w32,
- mangling for non-C languages: C++, Java,
- libtool should be able to add or remove a few symbols to the list,
- for w32, we may need to tag DATA exports,
Parsing is hard in the shell. It's probably easiest to define a
libtool-specific language (file format) that is easily amenable to sed
or old awk, from which we can generate a ld version script, a def file,
or a list of mangled symbols. That language could still allow the user
to specify arbitrarily complex version script constructions, as long as
they are given in a way our parser can easily ignore. That's the hard
part.
A complicating factor in the current libtool handling for exports is
line length limitations: we might need to cope with partial links or
reloadable objects, or, preferably, employ one of the workarounds like
response files or linker scripts. This part in ltmain I know how to
deal with, so if you need help there speak up.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
Mike Frysinger vap...@gentoo.org writes: alternative might be to do something like -export-symbols where libtool has its own method for managing lists of symbols, but extend it to handle versioning information as available with GNU/Solaris linkers. then that would take care of outputting the version script with the symbol prefix which libtool already knows. That might be a cleaner way of implementing the 80% solution. For most packages, I suspect that all you need to do is add the default symbol version string to the existing -export-symbols list as input parameters and then have libtool generate a symbol versioning file giving all symbols that version and listing everything in -export-symbols as global, with a local: *; section. There are nice things that you can do with a more sophisticated approach to versioning the symbols, but most use of symbol versioning is to avoid conflicts when multiple versions of a shared library are loaded at the same time, not to do more sophisticated things like provide multiple versions of a function bound to different symbol versions. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Wed, 23 Jun 2010 07:29, r...@stanford.edu said:
I can take a pass at starting. All that I need for my packages is to
support the basic version syntax:
version {
global:
symbol;
That would be sufficient for me too as long as a version_2 with only
global symbols is supported as well.
Having a second file with a simple list of symbols instead of a version
script parser is another option. Actually this is required because to
support W32 we need a .def file
EXPORTS
gcry_check_version @1
gcry_control @2
which allows to assign id numbers to symbols. In theory we could add
this via comment lines to a versions script but that would make a parser
even more complicated. In some projects I create the .def file from a
.def.in file to handle differences between W32 and W32CE. In any case
the .def file is easy to parse and could be used as input to
--export-symbols.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
Werner Koch w...@gnupg.org writes: (4) Let libtool do something. This may be an option to detect -Wl,--version-script=foo on the command line and hook in a sed to transform the symbols. It is pretty common that symols are all prefixed with something like foo_ or _foo_ and thus the option could take a list of these prefixes and - if a symbol prefix is required - transform the version script. I would dearly, dearly love for libtool to pick up a --version-script option that would pass in the full version script on platforms with linkers that understand it, turn it into a symbol export list on platforms that only support that, and suppress it entirely if the linker doesn't have any relevant capabilities. That would save me a ton of maintenance burden on some of my packages, and it would then be easy to add a feature like the above as well. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
Hello Russ, all, * Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST: I would dearly, dearly love for libtool to pick up a --version-script option that would pass in the full version script on platforms with linkers that understand it, turn it into a symbol export list on platforms that only support that, is this doable programmatically? Without a full version script parser? and suppress it entirely if the linker doesn't have any relevant capabilities. That would save me a ton of maintenance burden on some of my packages, and it would then be easy to add a feature like the above as well. Can somebody try to come up with a more detailed set of semantics, so we can judge a bit better whether this is feasible? If it is, any volunteers on implementing this? Do you know the gnulib module lib-symbol-versions? (No, it's not a complete solution.) Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
* Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST:
I would dearly, dearly love for libtool to pick up a --version-script
option that would pass in the full version script on platforms with
linkers that understand it, turn it into a symbol export list on
platforms that only support that,
is this doable programmatically? Without a full version script parser?
You would need a parser, but I don't think the parser needs to be
particularly complicated.
and suppress it entirely if the linker doesn't have any relevant
capabilities. That would save me a ton of maintenance burden on some
of my packages, and it would then be easy to add a feature like the
above as well.
Can somebody try to come up with a more detailed set of semantics, so we
can judge a bit better whether this is feasible? If it is, any
volunteers on implementing this?
I can take a pass at starting. All that I need for my packages is to
support the basic version syntax:
version {
global:
symbol;
symbol;
local:
*;
};
On platforms with linkers that support regular ELF versioning, libtool
would need to figure out the right flag to pass to the linker and then add
it to the link line. On platforms that don't support that sort of version
script, libtool should extract the symbols listed in the global section
and then treat this flag as equivalent to -export-symbols pointing to a
file containing just the list of symbols in the global section.
Obviously, there are a bunch of other things you can do with symbol
versioning and this wouldn't be a replacement for what, say, glibc does.
But I bet it would be a good 80% solution.
Do you know the gnulib module lib-symbol-versions? (No, it's not a
complete solution.)
I hadn't looked at it before. It looks like all that does is check
whether --version-script is supported by the linker. I suspect that will
only cover GNU ld and Solaris ld on ELF. The fallback to -export-symbols
is the main feature that I'd really like to see, since that's supported on
more platforms and satisfies another major reason why people use version
scripts.
I suppose one could use lib-symbol-versions in conjunction with a
separately-maintained or generated export symbols map and apply both of
them. I haven't tried that to see if there are any bad interactions
between -export-symbols and versioned symbols.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Wednesday, June 23, 2010 01:08:31 Ralf Wildenhues wrote: * Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST: I would dearly, dearly love for libtool to pick up a --version-script option that would pass in the full version script on platforms with linkers that understand it, turn it into a symbol export list on platforms that only support that, is this doable programmatically? Without a full version script parser? i guess it depends on how much you want to support. the full syntax is here: http://sourceware.org/binutils/docs/ld/VERSION.html the non-C language support makes me think it'd require a lot of work to be 100% complete, but ive personally never seen people use that in version scripts before (and ive quite a bit in the open source world). so if we kept the scope to C-only symbols ... the linker is pretty unforgiving of improperly formatted files (which works for us). since we only need to mung the symbol nodes, and those: - cannot have spaces - must be terminated by a semicolon - appear between the braces seems like it wouldnt be too bad ? alternative might be to do something like -export-symbols where libtool has its own method for managing lists of symbols, but extend it to handle versioning information as available with GNU/Solaris linkers. then that would take care of outputting the version script with the symbol prefix which libtool already knows. -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
