This is the mail archive of the ecos-discuss@sourceware.org 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: Re: Problem with CYG_HAL_TABLES


I think that I have identified the issue for me. The last member of MY_TYPE is a thread stack storage. It is declared as:

   /* Thread stack */
    cyg_uint8 stack[TASK_STK_SIZE] __attribute__((aligned(16)));

This apparently causes gcc to give the entire MY_TYPE object the same alignment, even though only that one member of MY_TYPE needs it. I worked around this by defining my own CYG_HAL_TABLE_BEGIN and CYG_HAL_TABLE_END macros with the alignment changed to CYGARC_ALIGNMENT. CYGARC_ALIGNMENT is 4, which is equivalent to __attribute__((aligned(16))).

Although not the cause of my issue, I think that CYG_HAL_TABLE_BEGIN, CYG_HAL_TABLE_END, and CYG_HAL_TABLE_TYPE should all use the same alignment.

Jay

On 1/25/2011 6:02 AM, Sergei Gavrikov wrote:
Hi Jay,

On Thu, 20 Jan 2011, Jay Foster wrote:

Looking at the definition of CYG_HAL_TABLE_TYPE and
CYG_HAL_TABLE_BEGIN, I see that the CYG_HAL_TABLE_BEGIN uses an
alignment of CYGARC_P2ALIGNMENT and the CYG_HAL_TABLE_TYPE uses an
alignment of CYGARC_ALIGNMENT.

For the ARM architecture, these are defined to be different
(CYGARC_P2ALIGNMENT is 2 and CYGARC_ALIGNMENT is 4).  This would
result in the table label being 4 byte aligned and the elements 16
byte aligned.
It seemed for me "P2" stands for "power of 2", so 2^2 == 4 and that is
okay ~ http://sourceware.org/binutils/docs/as/P2align.html

For example for i386 architecture they defined

# define CYGARC_ALIGNMENT 32
# define CYGARC_P2ALIGNMENT 5

i.e. 2^5 == 32

The question is why has this not caused me problems before this?
Jay, I tried your example 'as is' for a few ARM targets (LE/BE) (well I
could only guess what MY_TYPE is) and couldn't reproduce such a miss-
alignment for _MY_LABEL_.

I just use GDB to test your example for ARM targets

## .gdbinit --
set output-radix 16
target sim
print&(_MY_LABEL_)
print&(my_instance1)
detach
quit

This did print always the same addresses. Hm, puzzle. Just a guess, may
be you use some -falign-* GCC option? However, TAB macros written in
asm. And how did you declare the labels? Hope, that is something like

extern MY_TYPE  _MY_LABEL_[],
                 _MY_LABEL_END_;



Is it possible to reproduce the issue if you will provide more
information?


Sergei


On 1/20/2011 9:30 AM, Jay Foster wrote:
I have used the CYG_HAL_TABLE mechanism before with success, but I am now
running into an alignment problem with a new application.  This is on an ARM
architecture.

I have an object defined as:

typedef struct
{
  ....
} CYG_HAL_TABLE_TYPE MY_TYPE;

I then declare the HAL table array as:

CYG_HAL_TABLE_BEGIN( _MY_LABEL_, _my_name_ );
CYG_HAL_TABLE_END( _MY_LABEL_END_, _my_name_ );

I then place two instances of the object into the HAL table array:

MY_TYPE  my_instance1 CYG_HAL_TABLE_QUALIFIED_ENTRY(_my_name_, 2) =
{
     ....
};

MY_TYPE  my_instance2 CYG_HAL_TABLE_QUALIFIED_ENTRY(_my_name_, 3) =
{
     ....
};

I then iterate the table using:

MY_TYPE *p;

     for (p=&(_MY_LABEL_[0]); p!=&(_MY_LABEL_END_); p++)
     {
     }

This fails due to alignment issues:

     The _MY_LABEL_ is not at the same address as the first element in the
array (my_instance1) due to alignment issues.  The iteration then fails.
_MY_LABEL_ is aligned on a 4 byte boundary and the array elements are
aligned on 16 byte boundaries.  Is there any way to make this work?

Jay

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



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