[ECOS] _impure_ptr ??

[ECOS] _impure_ptr ??

[Bob Koninckx]

Upgraded to the 2.0 Beta. Got everything to compile, the eCos library
builds just fine. When linking my application however (powerpc-eabi
target, linux host), I get the following errors

powerpc-eabi-gcc
-L/home/bob/software/build/eCos/ec555/vbcom/library/ecos/install/lib
-Wl,-static -Wl,--gc-sections -nostartfiles -nostdlib -Xlinker -Map
-Xlinker vbcom.map -o bin/vbcom.elf .obj/vbcom.o library/vbcom.a
library/vbcom_extras.o
/home/bob/software/build/eCos/ec555/vbcom/library/sigc++/install/lib/libsigc++.a -lsupc++ -Ttarget.ld
/usr/local/crossgcc/powerpc-eabi/lib/gcc-lib/powerpc-eabi/3.2.1/../../../../powerpc-eabi/lib/libsupc++.a(pure.o): In function `__cxa_pure_virtual':
/home/bob/tmp/src/build_gcc/powerpc-eabi/libstdc++-v3/libsupc++/../../../../gcc-3.2.1/libstdc++-v3/libsupc++/pure.cc:49: undefined reference to `_impure_ptr'
/home/bob/tmp/src/build_gcc/powerpc-eabi/libstdc++-v3/libsupc++/../../../../gcc-3.2.1/libstdc++-v3/libsupc++/pure.cc:49: undefined reference to `_impure_ptr'
collect2: ld returned 1 exit status
make: *** [bin/vbcom.elf] Error 1

Anybody any idea ?
Could it be that something went wrong building the tools ?

Thanks,
Bob

-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------


-- 
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] _impure_ptr ??

[Gary D. Thomas]

On Sat, 2003-03-22 at 05:33, Bob Koninckx wrote:
> Upgraded to the 2.0 Beta. Got everything to compile, the eCos library
> builds just fine. When linking my application however (powerpc-eabi
> target, linux host), I get the following errors
> 
> powerpc-eabi-gcc
> -L/home/bob/software/build/eCos/ec555/vbcom/library/ecos/install/lib
> -Wl,-static -Wl,--gc-sections -nostartfiles -nostdlib -Xlinker -Map
> -Xlinker vbcom.map -o bin/vbcom.elf .obj/vbcom.o library/vbcom.a
> library/vbcom_extras.o
> /home/bob/software/build/eCos/ec555/vbcom/library/sigc++/install/lib/libsigc++.a -lsupc++ -Ttarget.ld
> /usr/local/crossgcc/powerpc-eabi/lib/gcc-lib/powerpc-eabi/3.2.1/../../../../powerpc-eabi/lib/libsupc++.a(pure.o): In function `__cxa_pure_virtual':
> /home/bob/tmp/src/build_gcc/powerpc-eabi/libstdc++-v3/libsupc++/../../../../gcc-3.2.1/libstdc++-v3/libsupc++/pure.cc:49: undefined reference to `_impure_ptr'
> /home/bob/tmp/src/build_gcc/powerpc-eabi/libstdc++-v3/libsupc++/../../../../gcc-3.2.1/libstdc++-v3/libsupc++/pure.cc:49: undefined reference to `_impure_ptr'
> collect2: ld returned 1 exit status
> make: *** [bin/vbcom.elf] Error 1
> 
> Anybody any idea ?
> Could it be that something went wrong building the tools ?

Does this happen for all programs, or just some?
Can you build the standard eCos tests?
Were you able to build this program before?

My guess is that you have a program that is using something
from libsupc++ that hasn't been tested/implemented.

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


-- 
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] _impure_ptr ??

[Bob Koninckx]

On Sat, 2003-03-22 at 13:48, Gary D. Thomas wrote:
> On Sat, 2003-03-22 at 05:33, Bob Koninckx wrote:
> > Upgraded to the 2.0 Beta. Got everything to compile, the eCos library
> > builds just fine. When linking my application however (powerpc-eabi
> > target, linux host), I get the following errors
> > 
> > powerpc-eabi-gcc
> > -L/home/bob/software/build/eCos/ec555/vbcom/library/ecos/install/lib
> > -Wl,-static -Wl,--gc-sections -nostartfiles -nostdlib -Xlinker -Map
> > -Xlinker vbcom.map -o bin/vbcom.elf .obj/vbcom.o library/vbcom.a
> > library/vbcom_extras.o
> > /home/bob/software/build/eCos/ec555/vbcom/library/sigc++/install/lib/libsigc++.a -lsupc++ -Ttarget.ld
> > /usr/local/crossgcc/powerpc-eabi/lib/gcc-lib/powerpc-eabi/3.2.1/../../../../powerpc-eabi/lib/libsupc++.a(pure.o): In function `__cxa_pure_virtual':
> > /home/bob/tmp/src/build_gcc/powerpc-eabi/libstdc++-v3/libsupc++/../../../../gcc-3.2.1/libstdc++-v3/libsupc++/pure.cc:49: undefined reference to `_impure_ptr'
> > /home/bob/tmp/src/build_gcc/powerpc-eabi/libstdc++-v3/libsupc++/../../../../gcc-3.2.1/libstdc++-v3/libsupc++/pure.cc:49: undefined reference to `_impure_ptr'
> > collect2: ld returned 1 exit status
> > make: *** [bin/vbcom.elf] Error 1
> > 
> > Anybody any idea ?
> > Could it be that something went wrong building the tools ?
> 
> Does this happen for all programs, or just some?
> Can you build the standard eCos tests?

Hi Gary,

Nope, linking tests fails, but here the error is that it does not find
operators new and delete. Has also to do with libsupc++, for sure. I am
trying to find out where the makefiles must be modified in order to get
libsupc++ added to the list of libraries

> Were you able to build this program before?

Yep, but that was with 2.95.2 ...

> 
> My guess is that you have a program that is using something
> from libsupc++ that hasn't been tested/implemented.

Looking further into it

> 
> -- 
> .--------------------------------------------------------.
> |       Mind: Embedded Linux and eCos Development        |
> |--------------------------------------------------------|
> | Gary Thomas              email:  gary.thomas@mind.be   |
> | Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
> | gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
> '--------------------------------------------------------'
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------


-- 
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] _impure_ptr ??

[Bob Koninckx]

Gary,

Just a small update on the situation.

If i provide my own definition 

extern "C" void
__cxa_pure_virtual(void) {}

and make sure the linker finds this one _before_ the stuff in libsupc++,
everything links ok. I am now going to debug the application and see if
everything still works as it should.

If this is all that needs to be done, that's fine with me. I suppose
more advanced recovery than the default message to stderr (apparently
that's what they do in newlib) could be necessary anyway.

Some further investigation showed that this __impure_ptr comes from
newlib for sure. Apparently, a 'write' function from newlib instead of
ecos libc gets called by __cxa_pure_virtual, which makes me cautious
about the compiler I build. Any idea how I can verify that my tools got
indeed build correctly ?

Bob

__

On Sat, 2003-03-22 at 14:01, Bob Koninckx wrote:
> On Sat, 2003-03-22 at 13:48, Gary D. Thomas wrote:
> > On Sat, 2003-03-22 at 05:33, Bob Koninckx wrote:
> > > Upgraded to the 2.0 Beta. Got everything to compile, the eCos library
> > > builds just fine. When linking my application however (powerpc-eabi
> > > target, linux host), I get the following errors
> > > 
> > > powerpc-eabi-gcc
> > > -L/home/bob/software/build/eCos/ec555/vbcom/library/ecos/install/lib
> > > -Wl,-static -Wl,--gc-sections -nostartfiles -nostdlib -Xlinker -Map
> > > -Xlinker vbcom.map -o bin/vbcom.elf .obj/vbcom.o library/vbcom.a
> > > library/vbcom_extras.o
> > > /home/bob/software/build/eCos/ec555/vbcom/library/sigc++/install/lib/libsigc++.a -lsupc++ -Ttarget.ld
> > > /usr/local/crossgcc/powerpc-eabi/lib/gcc-lib/powerpc-eabi/3.2.1/../../../../powerpc-eabi/lib/libsupc++.a(pure.o): In function `__cxa_pure_virtual':
> > > /home/bob/tmp/src/build_gcc/powerpc-eabi/libstdc++-v3/libsupc++/../../../../gcc-3.2.1/libstdc++-v3/libsupc++/pure.cc:49: undefined reference to `_impure_ptr'
> > > /home/bob/tmp/src/build_gcc/powerpc-eabi/libstdc++-v3/libsupc++/../../../../gcc-3.2.1/libstdc++-v3/libsupc++/pure.cc:49: undefined reference to `_impure_ptr'
> > > collect2: ld returned 1 exit status
> > > make: *** [bin/vbcom.elf] Error 1
> > > 
> > > Anybody any idea ?
> > > Could it be that something went wrong building the tools ?
> > 
> > Does this happen for all programs, or just some?
> > Can you build the standard eCos tests?
> 
> Hi Gary,
> 
> Nope, linking tests fails, but here the error is that it does not find
> operators new and delete. Has also to do with libsupc++, for sure. I am
> trying to find out where the makefiles must be modified in order to get
> libsupc++ added to the list of libraries
> 
> > Were you able to build this program before?
> 
> Yep, but that was with 2.95.2 ...
> 
> > 
> > My guess is that you have a program that is using something
> > from libsupc++ that hasn't been tested/implemented.
> 
> Looking further into it
> 
> > 
> > -- 
> > .--------------------------------------------------------.
> > |       Mind: Embedded Linux and eCos Development        |
> > |--------------------------------------------------------|
> > | Gary Thomas              email:  gary.thomas@mind.be   |
> > | Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
> > | gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
> > '--------------------------------------------------------'
> -- 
> ----------------------------------------------------------------------
> ir. Bob Koninckx
> Katholieke Universiteit Leuven
> Division Production Engineering,                   tel.  +32 16 322535
> Machine Design and Automation                      fax.  +32 16 322987
> Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
> B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
> ----------------------------------------------------------------------
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------


-- 
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] _impure_ptr ??

[Bob Koninckx]

This redefinition of __xca_pure_virtual seems to solve the problem. No
more link errors, application runs fins. Apparently, the compiler pulls
this function in as soon as you have at least one pure virtual function
in your application.

Problem is hereby signalled :-)

Bob

 
On Sat, 2003-03-22 at 14:49, Bob Koninckx wrote:
> Gary,
> 
> Just a small update on the situation.
> 
> If i provide my own definition 
> 
> extern "C" void
> __cxa_pure_virtual(void) {}
> 
> and make sure the linker finds this one _before_ the stuff in libsupc++,
> everything links ok. I am now going to debug the application and see if
> everything still works as it should.
> 
> If this is all that needs to be done, that's fine with me. I suppose
> more advanced recovery than the default message to stderr (apparently
> that's what they do in newlib) could be necessary anyway.
> 
> Some further investigation showed that this __impure_ptr comes from
> newlib for sure. Apparently, a 'write' function from newlib instead of
> ecos libc gets called by __cxa_pure_virtual, which makes me cautious
> about the compiler I build. Any idea how I can verify that my tools got
> indeed build correctly ?
> 
> Bob
> 
> __
> 
> On Sat, 2003-03-22 at 14:01, Bob Koninckx wrote:
> > On Sat, 2003-03-22 at 13:48, Gary D. Thomas wrote:
> > > On Sat, 2003-03-22 at 05:33, Bob Koninckx wrote:
> > > > Upgraded to the 2.0 Beta. Got everything to compile, the eCos library
> > > > builds just fine. When linking my application however (powerpc-eabi
> > > > target, linux host), I get the following errors
> > > > 
> > > > powerpc-eabi-gcc
> > > > -L/home/bob/software/build/eCos/ec555/vbcom/library/ecos/install/lib
> > > > -Wl,-static -Wl,--gc-sections -nostartfiles -nostdlib -Xlinker -Map
> > > > -Xlinker vbcom.map -o bin/vbcom.elf .obj/vbcom.o library/vbcom.a
> > > > library/vbcom_extras.o
> > > > /home/bob/software/build/eCos/ec555/vbcom/library/sigc++/install/lib/libsigc++.a -lsupc++ -Ttarget.ld
> > > > /usr/local/crossgcc/powerpc-eabi/lib/gcc-lib/powerpc-eabi/3.2.1/../../../../powerpc-eabi/lib/libsupc++.a(pure.o): In function `__cxa_pure_virtual':
> > > > /home/bob/tmp/src/build_gcc/powerpc-eabi/libstdc++-v3/libsupc++/../../../../gcc-3.2.1/libstdc++-v3/libsupc++/pure.cc:49: undefined reference to `_impure_ptr'
> > > > /home/bob/tmp/src/build_gcc/powerpc-eabi/libstdc++-v3/libsupc++/../../../../gcc-3.2.1/libstdc++-v3/libsupc++/pure.cc:49: undefined reference to `_impure_ptr'
> > > > collect2: ld returned 1 exit status
> > > > make: *** [bin/vbcom.elf] Error 1
> > > > 
> > > > Anybody any idea ?
> > > > Could it be that something went wrong building the tools ?
> > > 
> > > Does this happen for all programs, or just some?
> > > Can you build the standard eCos tests?
> > 
> > Hi Gary,
> > 
> > Nope, linking tests fails, but here the error is that it does not find
> > operators new and delete. Has also to do with libsupc++, for sure. I am
> > trying to find out where the makefiles must be modified in order to get
> > libsupc++ added to the list of libraries
> > 
> > > Were you able to build this program before?
> > 
> > Yep, but that was with 2.95.2 ...
> > 
> > > 
> > > My guess is that you have a program that is using something
> > > from libsupc++ that hasn't been tested/implemented.
> > 
> > Looking further into it
> > 
> > > 
> > > -- 
> > > .--------------------------------------------------------.
> > > |       Mind: Embedded Linux and eCos Development        |
> > > |--------------------------------------------------------|
> > > | Gary Thomas              email:  gary.thomas@mind.be   |
> > > | Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
> > > | gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
> > > '--------------------------------------------------------'
> > -- 
> > ----------------------------------------------------------------------
> > ir. Bob Koninckx
> > Katholieke Universiteit Leuven
> > Division Production Engineering,                   tel.  +32 16 322535
> > Machine Design and Automation                      fax.  +32 16 322987
> > Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
> > B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
> > ----------------------------------------------------------------------
> -- 
> ----------------------------------------------------------------------
> ir. Bob Koninckx
> Katholieke Universiteit Leuven
> Division Production Engineering,                   tel.  +32 16 322535
> Machine Design and Automation                      fax.  +32 16 322987
> Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
> B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
> ----------------------------------------------------------------------
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------


-- 
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] _impure_ptr ??

[Bart Veer]

>>>>> "Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:

    Bob> This redefinition of __xca_pure_virtual seems to solve the
    Bob> problem. No more link errors, application runs fins.
    Bob> Apparently, the compiler pulls this function in as soon as
    Bob> you have at least one pure virtual function in your
    Bob> application.

I have now reproduced this. Using a pure virtual function used to pull
in a function __pure_virtual_called() or something like that, which
was provided by libgcc.a and just aborted the application. That could
happen if somehow you managed to call a virtual function while the
base object was still being constructed, before the derived class
constructor had updated the virtual function table. Nowadays it
pulls in a more complicated __cxa_pure_virtual() from
libstdc++-v3/libsup++/pure.cc which has additional library
dependencies, unwanted ones in an eCos setup.

I think we want to put our own dummy __cxa_pure_virtual() into
CYGPKG_HAL or CYGPKG_INFRA. Jifl, any preferences ?

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
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] _impure_ptr ??

[Gary D. Thomas]

On Mon, 2003-03-24 at 14:26, Bart Veer wrote:
> >>>>> "Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:
> 
>     Bob> This redefinition of __xca_pure_virtual seems to solve the
>     Bob> problem. No more link errors, application runs fins.
>     Bob> Apparently, the compiler pulls this function in as soon as
>     Bob> you have at least one pure virtual function in your
>     Bob> application.
> 
> I have now reproduced this. Using a pure virtual function used to pull
> in a function __pure_virtual_called() or something like that, which
> was provided by libgcc.a and just aborted the application. That could
> happen if somehow you managed to call a virtual function while the
> base object was still being constructed, before the derived class
> constructor had updated the virtual function table. Nowadays it
> pulls in a more complicated __cxa_pure_virtual() from
> libstdc++-v3/libsup++/pure.cc which has additional library
> dependencies, unwanted ones in an eCos setup.
> 
> I think we want to put our own dummy __cxa_pure_virtual() into
> CYGPKG_HAL or CYGPKG_INFRA. Jifl, any preferences ?

If this is PowerPC only, then it goes in the HAL.
If it is common to all versions of GCC, then I would think INFRA.

-- 
.--------------------------------------------------------.
|       Mind: Embedded Linux and eCos Development        |
|--------------------------------------------------------|
| Gary Thomas              email:  gary.thomas@mind.be   |
| Mind ( http://mind.be )  tel:    +1 (970) 229-1963     |
| gpg: http://www.chez-thomas.org/gary/gpg_key.asc       |
'--------------------------------------------------------'


-- 
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] _impure_ptr ??

[Bob Koninckx]

It's a c++ thing, so I suppose it will be there for any platform

Bob

On Mon, 2003-03-24 at 22:31, Gary D. Thomas wrote:
> On Mon, 2003-03-24 at 14:26, Bart Veer wrote:
> > >>>>> "Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:
> > 
> >     Bob> This redefinition of __xca_pure_virtual seems to solve the
> >     Bob> problem. No more link errors, application runs fins.
> >     Bob> Apparently, the compiler pulls this function in as soon as
> >     Bob> you have at least one pure virtual function in your
> >     Bob> application.
> > 
> > I have now reproduced this. Using a pure virtual function used to pull
> > in a function __pure_virtual_called() or something like that, which
> > was provided by libgcc.a and just aborted the application. That could
> > happen if somehow you managed to call a virtual function while the
> > base object was still being constructed, before the derived class
> > constructor had updated the virtual function table. Nowadays it
> > pulls in a more complicated __cxa_pure_virtual() from
> > libstdc++-v3/libsup++/pure.cc which has additional library
> > dependencies, unwanted ones in an eCos setup.
> > 
> > I think we want to put our own dummy __cxa_pure_virtual() into
> > CYGPKG_HAL or CYGPKG_INFRA. Jifl, any preferences ?
> 
> If this is PowerPC only, then it goes in the HAL.
> If it is common to all versions of GCC, then I would think INFRA.
-- 
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering,                   tel.  +32 16 322535
Machine Design and Automation                      fax.  +32 16 322987
Celestijnenlaan 300B                  bob.koninckx@mech.kuleuven.ac.be
B-3001 Leuven Belgium               http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------


-- 
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] _impure_ptr ??

[Thomas Koeller]

I once proposed this, it has been rejected.
See http://sources.redhat.com/ml/ecos-patches/2002-06/msg00013.html
and related postings.

tk

On Montag, 24. März 2003 22:25, Bart Veer wrote:
> >>>>> "Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:
>
>     Bob> This redefinition of __xca_pure_virtual seems to solve the
>     Bob> problem. No more link errors, application runs fins.
>     Bob> Apparently, the compiler pulls this function in as soon as
>     Bob> you have at least one pure virtual function in your
>     Bob> application.
>
> I have now reproduced this. Using a pure virtual function used to pull
> in a function __pure_virtual_called() or something like that, which
> was provided by libgcc.a and just aborted the application. That could
> happen if somehow you managed to call a virtual function while the
> base object was still being constructed, before the derived class
> constructor had updated the virtual function table. Nowadays it
> pulls in a more complicated __cxa_pure_virtual() from
> libstdc++-v3/libsup++/pure.cc which has additional library
> dependencies, unwanted ones in an eCos setup.
>
> I think we want to put our own dummy __cxa_pure_virtual() into
> CYGPKG_HAL or CYGPKG_INFRA. Jifl, any preferences ?
>
> Bart
>
> --
> Bart Veer                       eCos Configuration Architect
> http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 

Thomas Koeller, Software Development

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Phone	+49 (4102) 463-390
Fax	+49 (4102) 463-46390

mailto:thomas.koeller@baslerweb.com
http://www.baslerweb.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] _impure_ptr ??

[Jonathan Larmour]

Bart Veer wrote:
>>>>>>"Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:
> 
> 
>     Bob> This redefinition of __xca_pure_virtual seems to solve the
>     Bob> problem. No more link errors, application runs fins.
>     Bob> Apparently, the compiler pulls this function in as soon as
>     Bob> you have at least one pure virtual function in your
>     Bob> application.
> 
> I have now reproduced this. Using a pure virtual function used to pull
> in a function __pure_virtual_called() or something like that, which
> was provided by libgcc.a and just aborted the application. That could
> happen if somehow you managed to call a virtual function while the
> base object was still being constructed, before the derived class
> constructor had updated the virtual function table. Nowadays it
> pulls in a more complicated __cxa_pure_virtual() from
> libstdc++-v3/libsup++/pure.cc which has additional library
> dependencies, unwanted ones in an eCos setup.
> 
> I think we want to put our own dummy __cxa_pure_virtual() into
> CYGPKG_HAL or CYGPKG_INFRA. Jifl, any preferences ?

CYGPKG_INFRA - there are dummy definitions of delete there for similar 
reasons.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- 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] _impure_ptr ??

[Bart Veer]

>>>>> "Gary" == Gary D Thomas <gary.thomas@mind.be> writes:

    Gary> On Mon, 2003-03-24 at 14:26, Bart Veer wrote:
    >> >>>>> "Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:
    >> 
    Bob> This redefinition of __xca_pure_virtual seems to solve the
    Bob> problem. No more link errors, application runs fins.
    Bob> Apparently, the compiler pulls this function in as soon as
    Bob> you have at least one pure virtual function in your
    Bob> application.
    >> 
    >> I have now reproduced this. Using a pure virtual function used to pull
    >> in a function __pure_virtual_called() or something like that, which
    >> was provided by libgcc.a and just aborted the application. That could
    >> happen if somehow you managed to call a virtual function while the
    >> base object was still being constructed, before the derived class
    >> constructor had updated the virtual function table. Nowadays it
    >> pulls in a more complicated __cxa_pure_virtual() from
    >> libstdc++-v3/libsup++/pure.cc which has additional library
    >> dependencies, unwanted ones in an eCos setup.
    >> 
    >> I think we want to put our own dummy __cxa_pure_virtual() into
    >> CYGPKG_HAL or CYGPKG_INFRA. Jifl, any preferences ?

    Gary> If this is PowerPC only, then it goes in the HAL. If it is
    Gary> common to all versions of GCC, then I would think INFRA.

It is target-independent - I reproduced it using an arm-elf toolchain.
There are precedents for putting it into CYGPKG_INFRA, e.g. memcpy().
However that was done before we had a common HAL package, CYGPKG_HAL.
I think there is actually an argument for moving memcpy() and
memmove() to the common HAL, leaving infra containing
assert/trace/testing support. That reasoning would place
__cxa_pure_virtual() in the common HAL as well.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
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] _impure_ptr ??

[Bart Veer]

>>>>> "Thomas" == Thomas Koeller <thomas@koeller.dyndns.org> writes:

    Thomas> I once proposed this, it has been rejected. See
    Thomas> http://sources.redhat.com/ml/ecos-patches/2002-06/msg00013.html
    Thomas> and related postings.

In due course, hopefully for eCos 2.1, we want eCos to have full
libstdc++ support. That will require quite a lot of functionality from
the existing libsupc++, not just __cxa_pure_virtual(). In particular
we'll probably want to reuse the libsupc++ exception handling support,
not replicate that stuff in eCos itself, because implementing
exception handling is nasty.

Hence the correct approach is to use as much as possible from the
existing libsupc++, overriding only when absolutely necessary.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
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] _impure_ptr ??

[Jonathan Larmour]

Bart Veer wrote:
> However that was done before we had a common HAL package, CYGPKG_HAL.
> I think there is actually an argument for moving memcpy() and
> memmove() to the common HAL, leaving infra containing
> assert/trace/testing support. That reasoning would place
> __cxa_pure_virtual() in the common HAL as well.

Actually thinking about it, I would argue that we should just make 
CYGPKG_LIBC_STRING compulsory. The package contains no weird and wacky 
constraints, and as it is, people have written code in eCos that just 
assumes these functions are present, without appropriate requires 
statements in CDL (although I've done my best to try and do this).

The single overhead is build time, and even that's not much.

The big plus is being able to _drop_ any CDL that checks whether its there 
or not. Simple string functions are virtually "infrastructure" in any 
environment. It also adds many simplifications elsewhere - just look at 
the testcases, plenty of which define their own versions of these 
functions just to be on the safe side.

No-one is going to write their own function called strcpy() that does 
something completely different, or if they do, it would just mask the one 
from the library anyway.

But if people don't like the idea of CYGPKG_LIBC_STRING being compulsory 
and therefore moving those functions back in there, they should continue 
to live in infra since they _are_ infrastructure, and have nothing 
whatsoever to do with hardware abstraction.

As for __cxa_pure_virtual(), again infra is right for the same reason.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- 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

[ECOS] "_impure_ptr"?

[Michele Portolan]

Hello, I am having some problems in adapting an application to eCos:
when I compile it by itself no problems, everyting works just fine.
If on the other hand I put it into an object and link it inside an eCos framework I get the following error:

D:\cygwin\home\portolan\testbenches\proto\src\aescrypt2-rc1/aes_monte_carlo.c:80: undefined reference to `_impure_ptr'
D:\cygwin\home\portolan\testbenches\proto\src\aescrypt2-rc1/aes_monte_carlo.c:80: undefined reference to `_impure_ptr'

What is this "_impure_ptr"? How can I resolve the error?
Thanks anyone,

Michele

PS: to be complete: here are the compiler calls

to create the object:
sparc-elf-gcc -g -O2 -msoft-float -I -I../../../build/mingw_ecos/install/include -msoft-float -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -Woverloaded-virtual -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -fvtable-gc -finit-priority -c -o ../../objs/aes_monte_carlo.o aes_monte_carlo.c

to link it:
sparc-elf-gcc  -g -msoft-float -nostartfiles -I../build/mingw_ecos/install/include -I./src/jpeg-6b -L../build/mingw_ecos/install/lib  -T../build/mingw_ecos/install/lib/target.ld -msoft-float -g -nostdlib -fvtable-gc -Wl,--gc-sections -Wl,-static -o proto_ecos proto_ecos.o objs/jpeg_interface.o ./objs/jdatadst.o ./objs/jpeg_compressor_thread.o ./objs/libjpeg.a  objs/aes_monte_carlo.o


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