public inbox for c++-embedded@sourceware.org
 help / color / mirror / Atom feed
* RE: gcc vs g++ and linking with as
@ 1998-06-25 11:36 Gary Mussar
  0 siblings, 0 replies; 8+ messages in thread
From: Gary Mussar @ 1998-06-25 11:36 UTC (permalink / raw)
  To: choward, Dave Hansen; +Cc: c++-embedded, crossgcc

> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* gcc vs g++ and linking with as
  1998-06-25  8:32 Chris Howard
  1998-06-25 20:20 ` C. M. Heard/VVNET, Inc.
  1998-06-25 23:03 ` Stephen Williams
@ 1998-06-26  0:59 ` Robert J. Brown
  2 siblings, 0 replies; 8+ messages in thread
From: Robert J. Brown @ 1998-06-26  0:59 UTC (permalink / raw)
  To: Chris Howard; +Cc: c++-embedded, crossgcc

>>>>> "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  ------

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc vs g++ and linking with as
  1998-06-25  8:32 Chris Howard
  1998-06-25 20:20 ` C. M. Heard/VVNET, Inc.
@ 1998-06-25 23:03 ` Stephen Williams
  1998-06-26  0:59 ` Robert J. Brown
  2 siblings, 0 replies; 8+ messages in thread
From: Stephen Williams @ 1998-06-25 23:03 UTC (permalink / raw)
  To: Chris Howard; +Cc: c++-embedded, crossgcc

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc vs g++ and linking with as
  1998-06-25  8:32 Chris Howard
@ 1998-06-25 20:20 ` C. M. Heard/VVNET, Inc.
  1998-06-25 23:03 ` Stephen Williams
  1998-06-26  0:59 ` Robert J. Brown
  2 siblings, 0 replies; 8+ messages in thread
From: C. M. Heard/VVNET, Inc. @ 1998-06-25 20:20 UTC (permalink / raw)
  To: Chris Howard; +Cc: c++-embedded, crossgcc

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: gcc vs g++ and linking with as
@ 1998-06-25 11:26 Gary Mussar
  0 siblings, 0 replies; 8+ messages in thread
From: Gary Mussar @ 1998-06-25 11:26 UTC (permalink / raw)
  To: choward, c++-embedded; +Cc: crossgcc

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc vs g++ and linking with as
       [not found] <s5923122.008@btree.com>
@ 1998-06-25 10:53 ` Chris Howard
  0 siblings, 0 replies; 8+ messages in thread
From: Chris Howard @ 1998-06-25 10:53 UTC (permalink / raw)
  To: Dave Hansen; +Cc: c++-embedded, crossgcc

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: gcc vs g++ and linking with as
@ 1998-06-25  9:21 Dave Hansen
  0 siblings, 0 replies; 8+ messages in thread
From: Dave Hansen @ 1998-06-25  9:21 UTC (permalink / raw)
  To: c++-embedded, choward; +Cc: crossgcc

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
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             !
                                   
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

^ permalink raw reply	[flat|nested] 8+ messages in thread

* gcc vs g++ and linking with as
@ 1998-06-25  8:32 Chris Howard
  1998-06-25 20:20 ` C. M. Heard/VVNET, Inc.
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Chris Howard @ 1998-06-25  8:32 UTC (permalink / raw)
  To: c++-embedded; +Cc: crossgcc

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~1998-06-26  0:59 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-06-25 11:36 gcc vs g++ and linking with as Gary Mussar
  -- strict thread matches above, loose matches on Subject: below --
1998-06-25 11:26 Gary Mussar
     [not found] <s5923122.008@btree.com>
1998-06-25 10:53 ` Chris Howard
1998-06-25  9:21 Dave Hansen
1998-06-25  8:32 Chris Howard
1998-06-25 20:20 ` C. M. Heard/VVNET, Inc.
1998-06-25 23:03 ` Stephen Williams
1998-06-26  0:59 ` Robert J. Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).