[ECOS] Re: ecos hal symbol table creation mechanism

[ECOS] Re: ecos hal symbol table creation mechanism

[Robert H]

2015-11-17 17:23 GMT+01:00 Sergei Gavrikov <sergei.gavrikov@gmail.com>:
> On Mon, 16 Nov 2015, Robert H wrote:
>
>> Hello all,
>>
>> I have some questions concerning the ecos hal symbol table creation in
>> hal_tables.h
>>
>> How is it possible to export a symbol which is in the ecos image into
>> some object file for it being able to call it?
>>
>> I know that test_mods.c uses some defines the object file - that the
>> application programer wants to load - uses some defines:
>> e.g.
>> CYG_LDR_TABLE_ENTRY(cyg_alarm_create_entry,"cyg_alarm_create",cyg_alarm_create);
>>
>> which then gets replaced by
>>
>> cyg_ldr_table_entry __name CYG_HAL_TABLE_ENTRY(ldr_table) = {
>> __symbol_name, __handler }; // line 141 in objelf.h
>> // with __name being a struct of
>> // { char *__symbol_name , void *__handler };
>> // where is the definition of ldr_table? I can't seem to find it anywhere
>>
>> and then again gets replaced by
>>
>> cyg_ldr_table_entry __name
>> __attribute__((section(".ecos.table.ldr_table.data")) = {
>> __symbol_name , __handler };
>> // line 103 in hal_tables.h
>>
>> Does the section attribute here tell the compiler to put a struct
>> cyg_ldr_tables_entry entry (in this example: {"cyg_alarm_create" ,
>> cyg_alarm_create} )
>> into the ecos image's section .ecos.table.ldr_table.data?
>
> Correct. Look on HAL arch. linker script(s). E.g. for ARM architecture
>
> https://sourceware.org/viewvc/ecos/packages/hal/arm/arch/current/src/arm.ld?revision=1.23&view=markup#l329
>
>> Then again, I wonder then how the ecos is able to get the adress of
>> the function/symbol cyg_alarm_create into the handler
>> cyg_alarm_create.
>>
>> I would be very pleased to know more about how the mechanism to get
>> ecos symbols works in hal_tables.h
>
> Generally and particularly (objloader case) the table boundaries are
> known
>
> https://sourceware.org/viewvc/ecos/packages/services/objloader/current/src/objelf.c?view=markup#l62
>
> Look up example, objelf.c:cyg_ldr_external_address():
>
> https://sourceware.org/viewvc/ecos/packages/services/objloader/current/src/objelf.c?view=markup#l219
>
>
> Sergei
Thank you very much Sergei!
I probably still don't get it by looking at the source code how
       entry->handler gets filled with the address of the symbol_name
in the ecos image.

cyg_ldr_external_address is for accessing the symbol table in that
section until the entry-pointer reached the cyg_ldr_table_end-pointer,
but to me that still doesn't explain how entry->handler gets filled by
the right address.

the application programmer maybe specifying the function he needs but
still I'm dunno how ecos achieves the address of a function from the
ecos image.


Robert

PS.:
I tried to illustrate the array of type struct cyg_ldr_table_entry
inside the section .ecos.table.ldr_table.data :

cyg_ldr_table
cyg_ldr_table_end
        |
                 |
        |
                 |
/--------------------\
  /--------------------\
| sym_name 1  |                                                   |
sym_name n   |
|--------------------|                    ..........
  |--------------------|
| handler 1        |
| handler n        |
\--------------------/
  \--------------------/
         |
         |
entry ++ ---->

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

Re: [ECOS] Re: ecos hal symbol table creation mechanism

[Sergei Gavrikov]

On Wed, 18 Nov 2015, Robert H wrote:

> 2015-11-17 Sergei Gavrikov wrote:
> > On Mon, 16 Nov 2015, Robert H wrote:

[snip]

> >> I would be very pleased to know more about how the mechanism to get
> >> ecos symbols works in hal_tables.h
> >
> > Generally and particularly (objloader case) the table boundaries are
> > known
> >
> > https://sourceware.org/viewvc/ecos/packages/services/objloader/current/src/objelf.c?view=markup#l62
> >
> > Look up example, objelf.c:cyg_ldr_external_address():
> >
> > https://sourceware.org/viewvc/ecos/packages/services/objloader/current/src/objelf.c?view=markup#l219

> I probably still don't get it by looking at the source code how
> entry->handler gets filled with the address of the symbol_name in the
> ecos image.
>
> cyg_ldr_external_address is for accessing the symbol table in that
> section until the entry-pointer reached the cyg_ldr_table_end-pointer,
> but to me that still doesn't explain how entry->handler gets filled by
> the right address.

Notice, that eCos table macros is a quite smart way to declare the
arrays of some C structure and keep them in a special memory region.

For your case the array's item (or "row" of the table) is C struct
cyg_ldr_table_entry:

  https://sourceware.org/viewvc/ecos/packages/services/objloader/current/include/objelf.h?revision=1.7&view=markup#l133

Similar in plain C

  extern int bar();
  extern int foo();

  struct s {
    char *name;
    void *call;
  };

  struct s table[] = { { "bar", bar }, {"foo", foo}, };
  struct s *table_end = &table[sizeof table / sizeof table[0]];

  struct s *entry = table;

  while(entry != table_end) {
    if(strcmp(entry->name, "foo") == 0) {
      return entry->call;
    }
    entry++;
  }

Hope, that no magic anymore.

Sergei

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