Mailing List Archive: GnuPG: gcrypt

Blackfin and version scripts

Index | Next | Previous | View Threaded

wk at gnupg

Jun 22, 2010, 2:42 AM

Post #1 of 17 (1530 views)
Permalink

Blackfin and version scripts

Hi!

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.

Now, versions scripts are using the symbols verbatim as in the C code:

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.

Ways to fix this are:

(1) Use autoconf to create a foo.vers from foo.vers.in while prefixing
all symbols like

GCRYPT_1.2 {
global:
@SYMBOL_PREFIX [at] gcry_check_versio; @SYMBOL_PREFIX [at] gcry_contro;
[...]

I think this looks too ugly and has also the drawback that we need to
get libtool's idea of the symbol prefix into autoconf. For libgcrypt
thsi is easy becuase due to the assembler modules we need to know it
anyway; but other libs don't need to know this.

(2) Another solution would be to sed the file on the fly in the
Makefile. This is better but requires that we need to maintain this
code in all projects.

(3) Introduce an new option in LD which tells it to use the native
symbol prefix of the platform for all symbols in the versions script.
This may take some time until it is implemneted and widely availabale.

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

Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

rra at stanford

Jun 22, 2010, 2:00 PM

Post #2 of 17 (1497 views)
Permalink

Re: Blackfin and version scripts [In reply to]

Werner Koch <wk [at] gnupg> 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 (rra [at] stanford) <http://www.eyrie.org/~eagle/>

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Ralf.Wildenhues at gmx

Jun 22, 2010, 10:08 PM

Post #3 of 17 (1502 views)
Permalink

Re: Blackfin and version scripts [In reply to]

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

rra at stanford

Jun 22, 2010, 10:29 PM

Post #4 of 17 (1495 views)
Permalink

Re: Blackfin and version scripts [In reply to]

Ralf Wildenhues <Ralf.Wildenhues [at] gmx> 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 (rra [at] stanford) <http://www.eyrie.org/~eagle/>

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

vapier at gentoo

Jun 22, 2010, 10:36 PM

Post #5 of 17 (1498 views)
Permalink

Re: Blackfin and version scripts [In reply to]

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

Attachments:

signature.asc (0.82 KB)

rra at stanford

Jun 22, 2010, 11:18 PM

Post #6 of 17 (1497 views)
Permalink

Re: Blackfin and version scripts [In reply to]

Mike Frysinger <vapier [at] gentoo> 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 (rra [at] stanford) <http://www.eyrie.org/~eagle/>

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

wk at gnupg

Jun 23, 2010, 12:46 AM

Post #7 of 17 (1499 views)
Permalink

Re: Blackfin and version scripts [In reply to]

On Wed, 23 Jun 2010 07:29, rra [at] stanford 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.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Ralf.Wildenhues at gmx

Jun 26, 2010, 12:32 PM

Post #8 of 17 (1490 views)
Permalink

Re: Blackfin and version scripts [In reply to]

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Ralf.Wildenhues at gmx

Jun 26, 2010, 12:36 PM

Post #9 of 17 (1486 views)
Permalink

Re: Blackfin and version scripts [In reply to]

* Werner Koch wrote on Wed, Jun 23, 2010 at 09:46:01AM CEST:
> On Wed, 23 Jun 2010 07:29, rra [at] stanford 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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

kurt at roeckx

Jul 3, 2010, 2:48 AM

Post #10 of 17 (1461 views)
Permalink

Re: Blackfin and version scripts [In reply to]

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

vapier at gentoo

Jul 5, 2010, 12:43 AM

Post #11 of 17 (1462 views)
Permalink

Re: Blackfin and version scripts [In reply to]

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

Attachments:

signature.asc (0.82 KB)

kurt at roeckx

Jul 5, 2010, 9:50 AM

Post #12 of 17 (1451 views)
Permalink

Re: Blackfin and version scripts [In reply to]

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

vapier.adi at gmail

Jul 5, 2010, 1:08 PM

Post #13 of 17 (1452 views)
Permalink

Re: Blackfin and version scripts [In reply to]

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

kurt at roeckx

Jul 6, 2010, 9:34 AM

Post #14 of 17 (1442 views)
Permalink

Re: Blackfin and version scripts [In reply to]

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

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

vapier at gentoo

Jul 6, 2010, 10:08 AM

Post #15 of 17 (1446 views)
Permalink

Re: Blackfin and version scripts [In reply to]

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

Attachments:

signature.asc (0.82 KB)

vapier at gentoo

Jul 19, 2010, 3:54 PM

Post #16 of 17 (1394 views)
Permalink

Re: Blackfin and version scripts [In reply to]

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

Attachments:

signature.asc (0.82 KB)

wk at gnupg

Jul 23, 2010, 11:35 PM

Post #17 of 17 (1370 views)
Permalink

Re: Blackfin and version scripts [In reply to]

Hi!

Ralf Wildenhues wrote on June 26:
> - 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,

For W32 we also need the ability to assign ordinal numbers. Actually
this is more important than the calling convention suffix because
allmost all new libs use C style. For example:

DllRegisterServer = DllRegisterServer@0 @2 PRIVATE

Which assigns the ordinal 2 to DllRegisterServer. I don't think the
complex syntax given above is really needed but nevertheless ordinals
are important to keep the ABI consistent,

Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads