RE: Re: [ECOS] linking problem when using "fopen"

RE: Re: [ECOS] linking problem when using "fopen"

[jyl087]

Jonathan Larmour <jlarmour@redhat.com> wrote:

>jyl087@netscape.net wrote:
>> 
>> Basically, I figured out that the
>>  "../arm-elf/2.95.2/libgcc.a" contains the "new" implementation,
>> which is needed by "fopen", and that object code requires all the
>> C++ cruft for exception handling. That's why the linker is barfing!
>> 
>> Obviously, my libgcc.a is different from yours. I built my tools
>> using the instructions found on the eCos site, and got these results.
>> I probably missed a step somewhere to build libgcc clean from C++
>> exception handling. Is that the case, or is it a matter of the
>> particular version (2.95.2) that I'm using?
>[snip]
>/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134:
>undefined reference to `type_info type_info node'
>> collect2: ld returned 1 exit status
>
>I've just looked a bit closer at this. I tried a simple test myself with
>some genuine 2.95.2 tools:
>
>#include <stdlib.h>
>
>int main(int argc, char *argv[])
>{
>    int *foo = new int;
>    *foo = rand();
>    return *foo;
>}
>
>Compiled with arm-elf-g++ -fno-exceptions -fno-rtti -ISOMETHING/include
>-LSOMETHING/lib  flib.cxx -Ttarget.ld -nostdlib -Wl,-Map,foo
>
>It worked fine, and the linker map includes:
>type_info type_info node
>                    0x8              
>/home/jlarmour/sourceware/gcc/egcs-2.95.2/build/arm-elf/install/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o)
>
>i.e. "type_info type_info node" is defined in tinfo.cc, which makes it all
>the more odd that you are seeing an undefined reference from that very
>file!
>
>An "arm-elf-nm -C" of the libgcc.a reveals that it should be defined as:
>00000008 C type_info type_info node, i.e. a "common" symbol. The same
>applies to other symbols that you are having problems with. It would be
>interesting to see what it says about your libgcc.a.
>
>So given the same gcc sources, I suspect the real problem here is something
>to do with your binutils.
>
>Jifl

Jonathan,

You've gone a bit over my head...  Naturally the above test
of "int *foo = new int" fails on my setup.

By the way, when you say that "type_info type_info node" is declared
in tinfo.cc... do you mean that there is a static var called "node"
of class "type_info" declared? I'm not sure I see that in my tinfo.cc.
What line?

Here's the "arm-elf-nm" dump of my libgcc.a. Only the "tinfo.o"
section is shown. 

Could it be that my binutils were compiled with a flag like
-fvtable-gc that caused my libgcc.a to be incomplete?

Let me know if there's anything else I should try...

Thanks,
/Jim

PS: On another subject - I think my previous difficulties with 
GDB over serial were due to hardware handshaking problems. I'm 
not exactly sure what I did to fix it, but it seems to work now...


---------------------------------------------------tinfo.o:
00000000 t .gcc2_compiled.
00000000 W _._14__si_type_info
00000000 W _._16__user_type_info
00000000 W _._17__class_type_info
00000000 T _._9type_info
00000624 T __14__si_type_infoPCcRC16__user_type_info
0000058c T __16__user_type_infoPCc
00000718 T __17__class_type_infoPCcPCQ217__class_type_info9base_infoUl
         U __builtin_delete
00000028 T __eq__C9type_infoRC9type_info
         U __get_eh_context
00000060 T __rtti_class
00000188 T __rtti_si
000002a4 T __rtti_user
00000000 W __tf14__si_type_info
00000000 W __tf16__user_type_info
00000000 W __tf17__class_type_info
         U __tf9type_info
0000000c C __ti14__si_type_info
0000000c C __ti16__user_type_info
0000000c C __ti17__class_type_info
         U __ti9type_info
00000000 V _vt.14__si_type_info
00000000 V _vt.16__user_type_info
00000000 V _vt.17__class_type_info
         U _vt.9type_info
00000394 T dcast__C14__si_type_infoRC9type_infoiPvPC9type_infoT3
00000370 T dcast__C16__user_type_infoRC9type_infoiPvPC9type_infoT3
00000400 T dcast__C17__class_type_infoRC9type_infoiPvPC9type_infoT3
         U strcmp



__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] linking problem when using "fopen"

[Jonathan Larmour]

jyl087@netscape.net wrote:
> 
> Jonathan Larmour <jlarmour@redhat.com> wrote:
> 
> You've gone a bit over my head...  Naturally the above test
> of "int *foo = new int" fails on my setup.
> 
> By the way, when you say that "type_info type_info node" is declared
> in tinfo.cc... do you mean that there is a static var called "node"
> of class "type_info" declared? I'm not sure I see that in my tinfo.cc.
> What line?

I think it's a side effect of "#pragma implementation "typeinfo"" near the
top.

> Here's the "arm-elf-nm" dump of my libgcc.a. Only the "tinfo.o"
> section is shown.
>
> Could it be that my binutils were compiled with a flag like
> -fvtable-gc that caused my libgcc.a to be incomplete?

Even if the binutils were compiled that way, it wouldn't affect the way
libgcc builds. If you are using genuine gcc 2.95.2 sources, this should
really just work. Here's my arm-elf-nm -C dump for tinfo.o for comparison
(the -C means to do the C++ name demangling):

tinfo.o:
00000000 t .gcc2_compiled.
00000718 T bad_typeid::~bad_typeid(void)
00000000 W __si_type_info::~__si_type_info(void)
00000000 W __user_type_info::~__user_type_info(void)
00000000 W __class_type_info::~__class_type_info(void)
00000664 T bad_cast::~bad_cast(void)
00000000 T type_info::~type_info(void)
0000068c T bad_typeid::bad_typeid(void)
000007d8 T __si_type_info::__si_type_info(char const *, __user_type_info
const &)
00000740 T __user_type_info::__user_type_info(char const *)
000008cc T __class_type_info::__class_type_info(char const *,
__class_type_info::base_info const *, unsigned long)
000005d8 T bad_cast::bad_cast(void)
0000058c T type_info::type_info(char const *)
         U __builtin_delete
00000028 T type_info::operator==(type_info const &) const
         U __get_eh_context
000005c0 T type_info::operator!=(type_info const &) const
00000060 T __rtti_class
00000188 T __rtti_si
000002a4 T __rtti_user
00000000 W bad_typeid type_info function
00000000 W __si_type_info type_info function
00000000 W __user_type_info type_info function
00000000 W __class_type_info type_info function
00000000 W bad_cast type_info function
         U exception type_info function
00000000 W type_info type_info function
0000000c C bad_typeid type_info node
0000000c C __si_type_info type_info node
0000000c C __user_type_info type_info node
0000000c C __class_type_info type_info node
0000000c C bad_cast type_info node
         U exception type_info node
00000008 C type_info type_info node
00000000 W bad_typeid virtual table
00000000 W __si_type_info virtual table
00000000 W __user_type_info virtual table
00000000 W __class_type_info virtual table
00000000 W bad_cast virtual table
         U exception virtual table
00000000 W type_info virtual table
00000394 T __si_type_info::dcast(type_info const &, int, void *, type_info
const *, void *) const
00000370 T __user_type_info::dcast(type_info const &, int, void *,
type_info const *, void *) const
00000400 T __class_type_info::dcast(type_info const &, int, void *,
type_info const *, void *) const
000005ac T type_info::name(void) const
         U strcmp
         U exception::what(void) const

 
> Let me know if there's anything else I should try...

Well if you're happy for now with a workaround for fopen in place, then
fair enough. But there is definitely something iffy with your tools. 2.95.2
sources shouldn't be different from the ones I built. The only suggestion
is that if you have any future problems, to downgrade your binutils sources
and rebuild your gcc from scratch using them.
 
> PS: On another subject - I think my previous difficulties with
> GDB over serial were due to hardware handshaking problems. I'm
> not exactly sure what I did to fix it, but it seems to work now...

Ah good.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] linking problem when using "fopen"

[Jonathan Larmour]

jyl087@netscape.net wrote:
> 
> Basically, I figured out that the
>  "../arm-elf/2.95.2/libgcc.a" contains the "new" implementation,
> which is needed by "fopen", and that object code requires all the
> C++ cruft for exception handling. That's why the linker is barfing!
> 
> Obviously, my libgcc.a is different from yours. I built my tools
> using the instructions found on the eCos site, and got these results.
> I probably missed a step somewhere to build libgcc clean from C++
> exception handling. Is that the case, or is it a matter of the
> particular version (2.95.2) that I'm using?
[snip]
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134:
undefined reference to `type_info type_info node'
> collect2: ld returned 1 exit status

I've just looked a bit closer at this. I tried a simple test myself with
some genuine 2.95.2 tools:

#include <stdlib.h>

int main(int argc, char *argv[])
{
    int *foo = new int;
    *foo = rand();
    return *foo;
}

Compiled with arm-elf-g++ -fno-exceptions -fno-rtti -ISOMETHING/include
-LSOMETHING/lib  flib.cxx -Ttarget.ld -nostdlib -Wl,-Map,foo

It worked fine, and the linker map includes:
type_info type_info node
                    0x8              
/home/jlarmour/sourceware/gcc/egcs-2.95.2/build/arm-elf/install/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o)

i.e. "type_info type_info node" is defined in tinfo.cc, which makes it all
the more odd that you are seeing an undefined reference from that very
file!

An "arm-elf-nm -C" of the libgcc.a reveals that it should be defined as:
00000008 C type_info type_info node, i.e. a "common" symbol. The same
applies to other symbols that you are having problems with. It would be
interesting to see what it says about your libgcc.a.

So given the same gcc sources, I suspect the real problem here is something
to do with your binutils.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] linking problem when using "fopen"

[Robin Farine]

On Fri, 2002-04-05 at 18:48, Jonathan Larmour wrote:

[...]

> > In this particular case, (new not overridden and no C++ exceptions), I
> > believe that a safe way to do it would first allocate the required space
> > using "new char [sizeof(...)]", and then if this doesn't return 0 then
> > call the placement operator new to actually create the object.
> 
> char's probably bad in case there are alignment issues (future/alternative
> versions of malloc may not align things so generously (i.e. wastefully).
> 

I do not agree, the new expression must return an address correctly
aligned according to ISO/IEC 14882:1998(E) 5.3.4 §10. But that's a
detail and your solution will perfectly do the job.

[...]

Robin



--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] linking problem when using "fopen"

[Jonathan Larmour]

Robin Farine wrote:
> 
> On Fri, 2002-04-05 at 10:45, Martin Buck wrote:
> > Jonathan Larmour wrote:
> > > > Using the non-throwing form of operator new might work:
> > > >
> > > >         new (std::nothrow) Cyg_StdioStream(...);
> > >
> > > I'm afraid I doubt this will work.
> >
> > I don't know about this problem here, but wouldn't "new (std::nothrow)"
> > be the correct solution anyway?
> >
> > IIRC, gcc assumes that the standard new always succeeds if it doesn't
> > throw an exception (which it can't in this case due to -fno-exceptions)
> > and calls the constructor without checking the return value from new. So
> > checking for curr_stream == NULL in fopen.cxx is useless because calling
> > Cyg_StdioStream's constructor with a NULL this pointer will most likely
> > already have caused a crash.

I thought that an effect of compiling with -fno-exceptions means that gcc
would automatically use the nothrow variant.

> Yes, good point Martin. However, the class Cyg_StdioStream could
> redefine new to use a preallocated heap and keep one slot for the error
> case for instance. Anyway, it would not return NULL.
> 
> In this particular case, (new not overridden and no C++ exceptions), I
> believe that a safe way to do it would first allocate the required space
> using "new char [sizeof(...)]", and then if this doesn't return 0 then
> call the placement operator new to actually create the object.

char's probably bad in case there are alignment issues (future/alternative
versions of malloc may not align things so generously (i.e. wastefully).

Anyway, I've changed it to allocate with malloc and use placement new
instead now.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] linking problem when using "fopen"

[Robin Farine]

On Fri, 2002-04-05 at 10:45, Martin Buck wrote:
> Jonathan Larmour wrote:
> > > Using the non-throwing form of operator new might work:
> > >
> > >         new (std::nothrow) Cyg_StdioStream(...);
> > 
> > I'm afraid I doubt this will work.
> 
> I don't know about this problem here, but wouldn't "new (std::nothrow)"
> be the correct solution anyway?
> 
> IIRC, gcc assumes that the standard new always succeeds if it doesn't
> throw an exception (which it can't in this case due to -fno-exceptions)
> and calls the constructor without checking the return value from new. So
> checking for curr_stream == NULL in fopen.cxx is useless because calling
> Cyg_StdioStream's constructor with a NULL this pointer will most likely
> already have caused a crash.

Yes, good point Martin. However, the class Cyg_StdioStream could
redefine new to use a preallocated heap and keep one slot for the error
case for instance. Anyway, it would not return NULL.

In this particular case, (new not overridden and no C++ exceptions), I
believe that a safe way to do it would first allocate the required space
using "new char [sizeof(...)]", and then if this doesn't return 0 then
call the placement operator new to actually create the object.

Robin



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] linking problem when using "fopen"

[Martin Buck]

Jonathan Larmour wrote:
> > Using the non-throwing form of operator new might work:
> >
> >         new (std::nothrow) Cyg_StdioStream(...);
> 
> I'm afraid I doubt this will work.

I don't know about this problem here, but wouldn't "new (std::nothrow)"
be the correct solution anyway?

IIRC, gcc assumes that the standard new always succeeds if it doesn't
throw an exception (which it can't in this case due to -fno-exceptions)
and calls the constructor without checking the return value from new. So
checking for curr_stream == NULL in fopen.cxx is useless because calling
Cyg_StdioStream's constructor with a NULL this pointer will most likely
already have caused a crash.

Martin

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] linking problem when using "fopen"

[Jonathan Larmour]

jyl087@netscape.net wrote:
> I'm using GCC 2.95.2. The libgcc.a associated with this compiler
> implements "new" with exceptions. Robin is on the right track, but
> the "new (std:nothrow)" form doesn't quite work, as Cyg_Stdio_Stream's
> constructor doesn't match the std:nothrow form of "new".
> 
> I found the solution in the ecos-discuss archives from Ryouzaburou
> Suzuki -
> 
>   http://sources.redhat.com/ml/ecos-discuss/2000-11/msg00235.html
> 
> Seems like this problem has been known for a couple of years. Why hasn't
> the fix been incorporated into the source tree?

Sort of because I don't like it because the fault is elsewhere. In
Ryouzaburou's case, the problem was because of his tools. In your case the
problem is surely because of your eCos sources (you haven't said what the
problem exactly is and what eCos sources you are using so I can't be sure).
I know it "works for me" :-).

I'll do you a deal: tell me what your problem is, and I'll make this change
even though I don't like it.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] linking problem when using "fopen"

[Jonathan Larmour]

Robin Farine wrote:
> 
> On Tue, 2002-04-02 at 00:13, jyl087@netscape.net wrote:
> > When I use the "fopen" call in my eCos application, I have problems
> > with linking. It seems that when "fopen_inner" calls "new Cyg_StdioStream"
> > it drags in all kinds of C++ exception handling cruft. I've verified
> > that fopen.cxx was compiled with "-fno_rtti -fno_exceptions", but
> > for some reason, the "new" call drags in all the RTTI and exception
> > handling stuff.
> >
> > I've verified that by commenting out the "new Cyg_StdioStream" call in
> > "fopen_inner" in the "fopen.cxx" file, my link errors go away, but
> > obviously fopen no longer works.
> >
> > Any ideas?
> 
> Using the non-throwing form of operator new might work:
> 
>         new (std::nothrow) Cyg_StdioStream(...);

I'm afraid I doubt this will work.

What C++ cruft does it pull in that causes a problem?

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] linking problem when using "fopen"

[Robin Farine]

On Tue, 2002-04-02 at 00:13, jyl087@netscape.net wrote:
> When I use the "fopen" call in my eCos application, I have problems
> with linking. It seems that when "fopen_inner" calls "new Cyg_StdioStream"
> it drags in all kinds of C++ exception handling cruft. I've verified
> that fopen.cxx was compiled with "-fno_rtti -fno_exceptions", but
> for some reason, the "new" call drags in all the RTTI and exception 
> handling stuff.
> 
> I've verified that by commenting out the "new Cyg_StdioStream" call in
> "fopen_inner" in the "fopen.cxx" file, my link errors go away, but
> obviously fopen no longer works.
> 
> Any ideas?

Using the non-throwing form of operator new might work:

	new (std::nothrow) Cyg_StdioStream(...);

Robin



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

[ECOS] linking problem when using "fopen"

[jyl087]

When I use the "fopen" call in my eCos application, I have problems
with linking. It seems that when "fopen_inner" calls "new Cyg_StdioStream"
it drags in all kinds of C++ exception handling cruft. I've verified
that fopen.cxx was compiled with "-fno_rtti -fno_exceptions", but
for some reason, the "new" call drags in all the RTTI and exception 
handling stuff.

I've verified that by commenting out the "new Cyg_StdioStream" call in
"fopen_inner" in the "fopen.cxx" file, my link errors go away, but
obviously fopen no longer works.

Any ideas?

Thanks,
/Jim


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss