[ECOS] Execution of constructors in at91

[ECOS] Execution of constructors in at91

[Rubén Pérez de Aranda Alonso]

Hello,
I am working with the at91 eb40 porting of eCOS to develop another port 
for a
prototype based on the same microcontroller. I now use the EmbeddedIce 
pod to
debug the eCOS and execute the tests of the different parts and layers, 
but I would
like use the Redboot and its GDB stub because it allows me write the 
falsh chips
and the comunication with the host is faster.
I have installed a redboot image in flash. With the load command in GDB 
I upload
the application in the RAM memory that has been compiled to be executed 
in RAM
and with a ROM monitor. The problem is when the eCOS startup code calls 
to the
cyg_hal_invoke_constructors() function. This function uses the symbols 
allocated by
the linker, __CTOR_LIST__ and __CTOR_END__, to know the address of the 
constructors
belonging to *.ctors binary sections of the different object files. The 
function calls to these
constructors without verify if the function pointer points to NULL, so 
the pc register branch
to the 0x0 address and execute the reset vector.
If I do not permit to target execute the call to this function 
(cyg_hal_invoke_constructors())
using the GDB, the  execution of the code goes on right until the 
execution of 
  HAL_THREAD_LOAD_CONTEXT( &next->stack_ptr )
in line 384 of sched.cxx file.
These two problems don't occur when I compile an image of the 
application with ROM
startup and I upload it to target with the Embedded ICE pod.

Thanks,

Rubén



-- 
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] Execution of constructors in at91

[Nick Garnett]

Rubén Pérez de Aranda Alonso <rperez@sidsa.es> writes:

> Hello,


> I am working with the at91 eb40 porting of eCOS to develop another
> port for a prototype based on the same microcontroller. I now use
> the EmbeddedIce pod to debug the eCOS and execute the tests of the
> different parts and layers, but I would like use the Redboot and its
> GDB stub because it allows me write the falsh chips and the
> comunication with the host is faster.  I have installed a redboot
> image in flash. With the load command in GDB I upload the
> application in the RAM memory that has been compiled to be executed
> in RAM and with a ROM monitor. The problem is when the eCOS startup
> code calls to the cyg_hal_invoke_constructors() function. This
> function uses the symbols allocated by the linker, __CTOR_LIST__ and
> __CTOR_END__, to know the address of the constructors belonging to
> *.ctors binary sections of the different object files. The function
> calls to these constructors without verify if the function pointer
> points to NULL, so the pc register branch to the 0x0 address and
> execute the reset vector.

There should not be NULL pointers in the constructor table. So the
thing to do is find out why they are there. Make sure you have not
corrupted the linker script in some way. Also, add the option
"-Wl,-Map,map" to the linker options, take a look at the map file
produced and see where the sections being added to the constructor
table are coming from.



-- 
Nick Garnett                    eCos Kernel 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] Execution of constructors in at91

[Rubén Pérez de Aranda Alonso]

Nick Garnett wrote:

>Rubén Pérez de Aranda Alonso <rperez@sidsa.es> writes:
>
>  
>
>>Hello,
>>    
>>
>
>
>  
>
>>I am working with the at91 eb40 porting of eCOS to develop another
>>port for a prototype based on the same microcontroller. I now use
>>the EmbeddedIce pod to debug the eCOS and execute the tests of the
>>different parts and layers, but I would like use the Redboot and its
>>GDB stub because it allows me write the falsh chips and the
>>comunication with the host is faster.  I have installed a redboot
>>image in flash. With the load command in GDB I upload the
>>application in the RAM memory that has been compiled to be executed
>>in RAM and with a ROM monitor. The problem is when the eCOS startup
>>code calls to the cyg_hal_invoke_constructors() function. This
>>function uses the symbols allocated by the linker, __CTOR_LIST__ and
>>__CTOR_END__, to know the address of the constructors belonging to
>>*.ctors binary sections of the different object files. The function
>>calls to these constructors without verify if the function pointer
>>points to NULL, so the pc register branch to the 0x0 address and
>>execute the reset vector.
>>    
>>
>
>There should not be NULL pointers in the constructor table. So the
>thing to do is find out why they are there. Make sure you have not
>corrupted the linker script in some way. Also, add the option
>"-Wl,-Map,map" to the linker options, take a look at the map file
>produced and see where the sections being added to the constructor
>table are coming from.
>
>
>
>  
>

Yesterday I found the problem.
When the firmware is configured with RAM startup the vectors.S does not 
contains the code to initialize the .data section
and the .ctors and .dtors sections of the object files are allocated in 
the .data section of the final binary file. I had configured
the linker script with LMA != VMA and RAM startup.
Another problem is when the the stack pointer of the stub code overlaps 
the .bss and/or .data sections of the application which
are being debugged. I resolved this adding a bigger offset  in the sram 
shared by the stub and the application. I seen this
behaviour debugging the ROM monitor throught the Embedded ICE at the 
same time I was debugging the application with the
ROM monitor throught the serial port of the target.




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