--wrap ld functionality does not work with Init RTEMS function

[Joel Sherrill]

Aitor Viana wrote:
> Hi,
>
>
> On Tue, Apr 8, 2008 at 9:12 PM, Joel Sherrill 
> <joel.sherrill at oarcorp.com <mailto:joel.sherrill at oarcorp.com>> wrote:
>
>     Aitor Viana wrote:
>
>         Hi all,
>
>
>
>
>         On Tue, Apr 8, 2008 at 7:38 PM, Thomas Dörfler
>         <Thomas.Doerfler at embedded-brains.de
>         <mailto:Thomas.Doerfler at embedded-brains.de>
>         <mailto:Thomas.Doerfler at embedded-brains.de
>         <mailto:Thomas.Doerfler at embedded-brains.de>>> wrote:
>
>            Hi,
>
>            Joel Sherrill schrieb:
>            > Aitor.Viana.Sanchez at esa.int
>         <mailto:Aitor.Viana.Sanchez at esa.int>
>         <mailto:Aitor.Viana.Sanchez at esa.int
>         <mailto:Aitor.Viana.Sanchez at esa.int>>
>
>            wrote:
>            >
>            >> Hi all,
>            >>
>            >> does anybody knows why when trying to wrap the Init
>         RTEMS function
>            >> with the ld --wrap functionality everything compiles
>         well but
>            >> eventually the wrapper function is not executed?
>            >>
>            >> Maybe I am missing something, but is taking me a while to
>            discover why.
>            >>
>            >>
>            > Init is a task/thread and threads will not return to the
>         wrapper.
>            > They are entered but exit via rtems_task_delete or
>         pthread_exit.
>            >
>            > I would expect the wrapper to be entered, then Init but
>         no return
>            > from Init.
>            >
>            Normally Init will be referenced from within the same
>         module: The
>            "init.c" module contains the first task AND the default
>         list in init
>            tasks (somehwere deep down in system.h -> confdefs.h). And
>         therefore I
>            would expect that the pointer in the list of init tasks
>         will point to
>            the REAL function, no matter how it might have been renamed.
>
>            Does this make sense?
>
>
>         yes, I think this is the problem, the indirect point. Because
>         when trying to wrap the Init function, the wrapper function
>         (__wrap_Init()) is never called, maybe because it is called
>         from an indirect pointer.
>         I will try to dig deeply...but I would really need to wrap the
>         Init function (task, thread, whatever).
>
>     My example worked with an indirect function pointer.
>     Can you look at the Initialization_tasks[] structure contents on
>     the target?
>     That way we can see if the table entry was right.
>
>
> Yes sorry, I didn't check it out...now I see that is working with 
> indirect pointers.
>
> now I cannot look at the Initialization_tasks[] structure per se, 
> because I am at home. But I can send the configuration so we maybe we 
> can figure out the Initialization_tasks[]
We know that the entry point should be Init but the loader has to change
that to be wrap_Init and real_Init.  This linker trick may only substitute
in so many cases.   I can see where an indirect pointer through a table
might break it.
>
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>
> #define CONFIGURE_MAXIMUM_TASKS     10
>
> #define CONFIGURE_INIT_TASK_PRIORITY    1
> #define CONFIGURE_INIT_TASK_INITIAL_MODES   RTEMS_PREEMPT
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
>
> #define CONFIGURE_INIT
> #include <rtems/confdefs.h>
>
>
>  
>
>
>
>
>            wkr,
>            Thomas.
>
>            >> Regards,
>            >>
>            >> Aitor
>            >>
>            >
>            >
>            >
>
>
>            --
>            --------------------------------------------
>            embedded brains GmbH
>            Thomas Doerfler           Obere Lagerstr. 30
>            D-82178 Puchheim          Germany
>            Tel. : +49-89-18 90 80 79-2
>            Fax  : +49-89-18 90 80 79-9
>            email: Thomas.Doerfler at embedded-brains.de
>         <mailto:Thomas.Doerfler at embedded-brains.de>
>            <mailto:Thomas.Doerfler at embedded-brains.de
>         <mailto:Thomas.Doerfler at embedded-brains.de>>
>
>            PGP public key available on request
>
>            Diese Nachricht ist keine geschäftliche Mitteilung im Sinne
>         des EHUG.
>
>            _______________________________________________
>            rtems-users mailing list
>            rtems-users at rtems.com <mailto:rtems-users at rtems.com>
>         <mailto:rtems-users at rtems.com <mailto:rtems-users at rtems.com>>
>
>            http://rtems.rtems.org/mailman/listinfo/rtems-users
>
>
>
>
>     -- 
>     Joel Sherrill, Ph.D.             Director of Research & Development
>     joel.sherrill at OARcorp.com        On-Line Applications Research
>     Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>      Support Available             (256) 722-9985
>
>
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985