This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: add .cc files to libgcc.a

On Oct 29, 2012, at 1:47 PM, Jonathan Wakely wrote:

> It compiles fine with gcc if you put it in a file that ends in .cc or
> .C or .cpp or any of the other extensions that tell gcc to run the
> cc1plus compiler.  Please read

I didn't see this before... but I'm still not clear why the distinction is important to you.

cc1plus is needed.  So, gcc can call cc1plus.  What can't I use the term "g++" for that path?  Isn't that how people think of it?  How is the fact that gcc can call cc1plus really significantly important?  We all know that gcc and g++ are just front ends.

Also, in my original implementation, the new code does get put into both libsupc++ and libstdc++.  It appeared to me that libsupc++ is a proper subset of libstdc++.  In fact, this link is where I got that idea from:

Note also that __cxa_guard_* is in the libsupc++ and libstdc++ libraries as well (and not libgcc).  Here is the nm output of the libraries after my additions:

> nm -Bx libsupc++.a | egrep '__cxa_atexit|__cxa_finalize|__cxa_guard'
> 0x000001a8 T .__cxa_guard_abort
> 0x000001a8 t .__cxa_guard_abort
> 0x000000f0 T .__cxa_guard_acquire
> 0x000000f0 t .__cxa_guard_acquire
> 0x000001e4 T .__cxa_guard_release
> 0x000001e4 t .__cxa_guard_release
> 0x00000284 D __cxa_guard_abort
> 0x00000284 d __cxa_guard_abort
> 0x00000278 D __cxa_guard_acquire
> 0x00000278 d __cxa_guard_acquire
> 0x00000290 D __cxa_guard_release
> 0x00000290 d __cxa_guard_release
> 0x00000278 T .__cxa_atexit
> 0x00000278 t .__cxa_atexit
> 0x00000318 D __cxa_atexit
> 0x00000318 d __cxa_atexit
> 0x00000080 T .__cxa_finalize
> 0x00000080 t .__cxa_finalize
> 0x000001fc D __cxa_finalize
> 0x000001fc d __cxa_finalize

> nm -Bx libstdc++.a | egrep '__cxa_atexit|__cxa_finalize|__cxa_guard'
> 0x1009d630 T .__cxa_atexit
> 0x1009d630 t .__cxa_atexit
> 0x100a9d34 T .__cxa_atexit
> 0x100a9d34 t .__cxa_atexit
> 0x1009ca3c T .__cxa_finalize
> 0x1009ca3c t .__cxa_finalize
> 0x1009cbfc T .__cxa_finalize
> 0x1009cbfc t .__cxa_finalize
> 0x100ccb8c T .__cxa_guard_abort
> 0x100ccb8c t .__cxa_guard_abort
> 0x100ccbc8 T .__cxa_guard_abort
> 0x100ccbc8 t .__cxa_guard_abort
> 0x1000d170 T .__cxa_guard_acquire
> 0x1000d170 t .__cxa_guard_acquire
> 0x1009d9ac T .__cxa_guard_acquire
> 0x1009d9ac t .__cxa_guard_acquire
> 0x1000d428 T .__cxa_guard_release
> 0x1000d428 t .__cxa_guard_release
> 0x1009d9fc T .__cxa_guard_release
> 0x1009d9fc t .__cxa_guard_release
> 0x2002886c D __cxa_atexit
> 0x2002886c d __cxa_atexit
> 0x2002e650 d __cxa_atexit
> 0x20027354 D __cxa_finalize
> 0x20027354 d __cxa_finalize
> 0x2002dbe4 d __cxa_finalize
> 0x2002d270 D __cxa_guard_abort
> 0x2002d270 d __cxa_guard_abort
> 0x20030600 d __cxa_guard_abort
> 0x2002748c D __cxa_guard_acquire
> 0x2002748c d __cxa_guard_acquire
> 0x2002dccc d __cxa_guard_acquire
> 0x200274a4 D __cxa_guard_release
> 0x200274a4 d __cxa_guard_release
> 0x2002dcd4 d __cxa_guard_release

As far as the code, yes... the base code in glibc is C code but it called locking functions that was glibc specific.  Since it appeared that I was going to add it to libsupc++ (I guess you prefer that name), I used the locking that is uses.  Here is my comment at the top of the file.

> /*
>  * Notes: This code essentially came from glibc version 2.16.0.  It is
>  * "C" code there.  I stole mutex_wrapper from
>  */


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]