binutils 2.9 gcc/g++ 2.8.0 Host Sun Sparc Solaris 2.5 Target Motorola Coldfire (-m5200) a.out object format --- Not using stdlib (-nostdlib) We have some code in assembler, and some in C. Compiling with as,gcc and linking with ld works fine. Compiling with as,g++ and linking with ld does not work, undefined symbols for those things written in assembler. The .o files output from g++ compilation have exported symbols that end in '__Fv' whereas the assembler output .o files don't have '__Fv' on the symbols. Is that the problem? Is there some way to make it work? What is __Fv? An alternative might be to put the assembly code in C/C++ wrapper functions. Any hints/comments that would be appreciated also. -- Chris Howard Fujitsu Computer Products of America Longmont, Colorado
This is the name mangling that g++ uses to resolve overloaded functions.
To prevent this, declare the assembly functions as extern "C" in the
C++ code. For example:
extern "C" asm_fn();
HTH. Regards,
-=Dave
>>> Chris Howard <choward@intellistor.com> 06/25/98 10:29AM >>>
binutils 2.9
gcc/g++ 2.8.0
Host Sun Sparc Solaris 2.5
Target Motorola Coldfire (-m5200) a.out object format
---
Not using stdlib (-nostdlib)
We have some code in assembler, and some in C.
Compiling with as,gcc and linking with ld works fine.
Compiling with as,g++ and linking with ld does not work,
undefined symbols for those things written in assembler.
The .o files output from g++ compilation have exported symbols that
end in '__Fv' whereas the assembler output .o files don't have
'__Fv' on the symbols. Is that the problem? Is there
some way to make it work? What is __Fv?
An alternative might be to put the assembly code in
C/C++ wrapper functions. Any hints/comments that
would be appreciated also.
--
Chris Howard Fujitsu Computer Products of America
Longmont, Colorado
!
But none of it is C++ code. It's all C or assembler.
Shouldn't gcc and g++ compile a *.c file the same way?
Also, we have calls going both ways c-->asm() asm-->c()
Sounds like name mangling will make asm-->c++() impossible (?)
Dave Hansen wrote:
>
> This is the name mangling that g++ uses to resolve overloaded functions.
> To prevent this, declare the assembly functions as extern "C" in the
> C++ code. For example:
>
> extern "C" asm_fn();
>
> HTH. Regards,
>
> -=Dave
>
> >>> Chris Howard <choward@intellistor.com> 06/25/98 10:29AM >>>
> binutils 2.9
> gcc/g++ 2.8.0
>
> Host Sun Sparc Solaris 2.5
> Target Motorola Coldfire (-m5200) a.out object format
>
> ---
>
> Not using stdlib (-nostdlib)
>
> We have some code in assembler, and some in C.
> Compiling with as,gcc and linking with ld works fine.
> Compiling with as,g++ and linking with ld does not work,
> undefined symbols for those things written in assembler.
>
> The .o files output from g++ compilation have exported symbols that
> end in '__Fv' whereas the assembler output .o files don't have
> '__Fv' on the symbols. Is that the problem? Is there
> some way to make it work? What is __Fv?
>
> An alternative might be to put the assembly code in
> C/C++ wrapper functions. Any hints/comments that
> would be appreciated also.
>
> --
> Chris Howard Fujitsu Computer Products of America
> Longmont, Colorado
>
--
Chris Howard Fujitsu Computer Products of America
Longmont, Colorado
The gcc shell will examine the suffix of the source file to determine if the
language is C or C++. The g++ shell assumes the language is C++ no matter
what the source file extension is. As a result, your file has been compiled
as a C++ file rather than a C file and C++ name mangling has been applied.
Dave Hansen suggested using extern "C" around the appropriate sections of
code where you don't want C++ name mangling to occur.
You can tell g++ that the source file is really C rather than C++ with the
-x c option.
You can modify you assembler routines to specify mangled names (which is not
really recommended because the name mangling scheme can change from release
to release).
> -----Original Message-----
> binutils 2.9
> gcc/g++ 2.8.0
>
> Host Sun Sparc Solaris 2.5
> Target Motorola Coldfire (-m5200) a.out object format
>
> ---
>
> Not using stdlib (-nostdlib)
>
> We have some code in assembler, and some in C.
> Compiling with as,gcc and linking with ld works fine.
> Compiling with as,g++ and linking with ld does not work,
> undefined symbols for those things written in assembler.
>
> The .o files output from g++ compilation have exported symbols that
> end in '__Fv' whereas the assembler output .o files don't have
> '__Fv' on the symbols. Is that the problem? Is there
> some way to make it work? What is __Fv?
>
>
> An alternative might be to put the assembly code in
> C/C++ wrapper functions. Any hints/comments that
> would be appreciated also.
>
>
> --
> Chris Howard Fujitsu Computer Products of America
> Longmont, Colorado
> But none of it is C++ code. It's all C or assembler. > Shouldn't gcc and g++ compile a *.c file the same way? > No, gcc and g++ shells are almost alike but g++ always assumes that the source is c++ rather than examining the extension to make that determination. > Also, we have calls going both ways c-->asm() asm-->c() > > Sounds like name mangling will make asm-->c++() impossible (?) > Its not impossible. You need to either know what the mangled name is to invoke the routine (not recommended because it changes) or you need to create the routine with C++ name mangling (using the C++ extern "C" stuff). Turning off name mangling for a particular function will prevent you from overloading that function. You are treading on dangerous ground if you attempt to call member functions of C++ objects because you will need to know the internals of how the "this" pointer is passed around, etc.. Gary > Dave Hansen wrote: > > > > This is the name mangling that g++ uses to resolve overloaded functions. > > To prevent this, declare the assembly functions as extern "C" in the > > C++ code. For example: > > > > extern "C" asm_fn(); > > > > HTH. Regards, > > > > -=Dave > > > > >>> Chris Howard <choward@intellistor.com> 06/25/98 10:29AM >>> > > binutils 2.9 > > gcc/g++ 2.8.0 > > > > Host Sun Sparc Solaris 2.5 > > Target Motorola Coldfire (-m5200) a.out object format > > > > --- > > > > Not using stdlib (-nostdlib) > > > > We have some code in assembler, and some in C. > > Compiling with as,gcc and linking with ld works fine. > > Compiling with as,g++ and linking with ld does not work, > > undefined symbols for those things written in assembler. > > > > The .o files output from g++ compilation have exported symbols that > > end in '__Fv' whereas the assembler output .o files don't have > > '__Fv' on the symbols. Is that the problem? Is there > > some way to make it work? What is __Fv? > > > > An alternative might be to put the assembly code in > > C/C++ wrapper functions. Any hints/comments that > > would be appreciated also. > > > > -- > > Chris Howard Fujitsu Computer Products of America > > Longmont, Colorado > > > > > -- > Chris Howard Fujitsu Computer Products of America > Longmont, Colorado
On Thu, 25 Jun 1998, Chris Howard wrote: > binutils 2.9 > gcc/g++ 2.8.0 > > Host Sun Sparc Solaris 2.5 > Target Motorola Coldfire (-m5200) a.out object format > > --- > > Not using stdlib (-nostdlib) > > We have some code in assembler, and some in C. > Compiling with as,gcc and linking with ld works fine. > Compiling with as,g++ and linking with ld does not work, > undefined symbols for those things written in assembler. > > The .o files output from g++ compilation have exported symbols that > end in '__Fv' whereas the assembler output .o files don't have > '__Fv' on the symbols. Is that the problem? Is there > some way to make it work? What is __Fv? The C++ compiler "mangles" the names of functions in order to encode the type and number of arguments and the return type. You can turn that off by declaring that the function uses C linkage conventions (as you will see if you look at the system header files on your Solaris host): extern "C" { <declarations of stuff that uses C linkage> } I always do that in my own embedded work when I write functions or define data structures in assembler language that I wish to use in C or C++ programs. I also do that when I want to write a function in C++ that I can call from C or assembler language programs. In these cases I make one header file that can be included in modules written in any of these languages. Here is an actual example: /* * jobqueue.h - kernel entry points for job queue maintenance * * Copyright (c) 1996 VVNET, Inc. * All Rights Reserved. */ #ifndef _JOBQUEUE_H #define _JOBQUEUE_H #include "jqe.h" #ifndef __ASSEMBLER__ #ifdef __cplusplus extern "C" { #endif void jobqueue_init (void); int get_jqe (JQE_PTR p); #ifdef __cplusplus } #endif #else /* ifdef __ASSEMBLER__ */ .globl jobqueue_init .globl get_jqe #endif /* __ASSEMBLER__ */ #endif /* _JOBQUEUE_H */ As it happens, both of these functions are implemented in assembler language, but the same header file would work if one or both was written in C or C++. > An alternative might be to put the assembly code in > C/C++ wrapper functions. Any hints/comments that > would be appreciated also. By that I presume you mean using in-line assembler. That does have certain advantages if you take the time to learn how use extended inline asembler to let gcc automatically select free scratch registers, bind registers to calling parameters, etc. I do this for certain macros I want to inline but as a rule I prefer to use the assembler when I am writing straight assembler code. For more info read the gcc info files (search for the string "Extended Asm"). > Chris Howard Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com
choward@intellistor.com said: > Compiling with as,gcc and linking with ld works fine. Compiling with > as,g++ and linking with ld does not work, > undefined symbols for those things written in assembler. Even in C you can have troubles. What I do is use the "asm" attribute to declare external variables, i.e.: extern unsigned char __index_space asm("__index_space__"); which causes __index_space__ to be the actual symbol name at link time. A function would work like this: int foo(int i) asm("test_symbol"); int foo(int i) { return i+1; } This works with (GNU) C and C++. It is a good thing to do even with C because sometimes you get the leasing _, sometimes you don't. etc. -- Steve Williams "The woods are lovely, dark and deep. steve@icarus.com But I have promises to keep, steve@picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."
>>>>> "Chris" == Chris Howard <choward@intellistor.com> writes: Chris> binutils 2.9 gcc/g++ 2.8.0 Chris> Host Sun Sparc Solaris 2.5 Target Motorola Coldfire Chris> (-m5200) a.out object format Chris> --- Chris> Not using stdlib (-nostdlib) Chris> We have some code in assembler, and some in C. Compiling Chris> with as,gcc and linking with ld works fine. Compiling with Chris> as,g++ and linking with ld does not work, undefined symbols Chris> for those things written in assembler. You will have to declare the asm routines "extern 'C'" because the assembler does not perform C++ name mangling for you. Chris> The .o files output from g++ compilation have exported Chris> symbols that end in '__Fv' whereas the assembler output .o Chris> files don't have '__Fv' on the symbols. Is that the Chris> problem? Is there some way to make it work? What is __Fv? These are C++ mangled names. Use c++filt to de-mangle C++ mangled names. The mangling encodes type information into the names so that the linker can resolve functions with the same name but different signatures. Chris> An alternative might be to put the assembly code in C/C++ Chris> wrapper functions. Any hints/comments that would be Chris> appreciated also. This is not necessary -- just declare the asm functions extern 'C' and the compiler will know not to mangle those names, so the linker will be able to resolve them. Chris> -- Chris Howard Fujitsu Computer Products of America Chris> Longmont, Colorado -- -------- "And there came a writing to him from Elijah" [2Ch 21:12] -------- R. J. Brown III rj@elilabs.com http://www.elilabs.com/~rj voice 847 543-4060 Elijah Laboratories Inc. 457 Signal Lane, Grayslake IL 60030 fax 847 543-4061 ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d ------