This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos 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: Help with linux synthetic target, please.


>>>>> "Gordon" == Gordon Scott <g.ecos.a@gscott.co.uk> writes:

    Gordon> On Mon, 8 Mar 2004, Bart Veer wrote:
    >> Unfortunately the fix came after the eCos 2.0 release. You can switch
    >> to anoncvs or a recent snapshot. Alternatively you can just add the
    >> following to the end of src/synth_entry.c:
    >> 
    >> #if (__GNUC__ < 3)
    >> // 2.95.x libgcc.a __pure_virtual() calls __write().
    >> int __write(void)
    >> {
    >> return -1;
    >> }
    >> #endif

    Gordon> That's painless, except my gcc is 3.3.2. Is this believed
    Gordon> fixed in 3.3.2?

3.3.2 needs different changes to synth_entry.c. At least the ones
below, possibly more, I have not yet tried anything > 3.2.2 myself.

----------------------------------------------------------------------------
#if (__GNUC__ >= 3)
// Versions of gcc/g++ after 3.0 (approx.), when configured for Linux
// native development (specifically, --with-__cxa_enable), have
// additional dependencies related to the destructors for static
// objects. When compiling C++ code with static objects the compiler
// inserts a call to __cxa_atexit() with __dso_handle as one of the
// arguments. __cxa_atexit() would normally be provided by glibc, and
// __dso_handle is part of crtstuff.c. Synthetic target applications
// are linked rather differently, so either a differently-configured
// compiler is needed or dummy versions of these symbols should be
// provided. If these symbols are not actually used then providing
// them is still harmless, linker garbage collection will remove them.

void
__cxa_atexit(void (*arg1)(void*), void* arg2, void* arg3)
{
}
void*   __dso_handle = (void*) &__dso_handle;

// gcc 3.2.2 (approx). The libsupc++ version of the new operator pulls
// in exception handling code, even when using the nothrow version and
// building with -fno-exceptions. libgcc_eh.a provides the necessary
// functions, but requires a dl_iterate_phdr() function. That is related
// to handling dynamically loaded code so is not applicable to eCos.
int
dl_iterate_phdr(void* arg1, void* arg2)
{
    return -1;
}
#endif
----------------------------------------------------------------------------

    Gordon> Oh, right .. that's the version that _libgcc_ belongs to.
    Gordon> Presumably I have an old libgcc. I definitely should fix
    Gordon> that!

If you are trying to use gcc 3.3.2 with a 2.95.3 libgcc then you can
expect lots of things to go horribly wrong. gcc and libgcc must be
kept in step.

Bart

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

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


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