This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Question about CYG_HAL_TABLE usage
- From: Grant Edwards <grant dot b dot edwards at gmail dot com>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Sat, 12 Oct 2013 15:19:23 +0000 (UTC)
- Subject: Re: Question about CYG_HAL_TABLE usage
- Authentication-results: sourceware.org; auth=none
- References: <l39rn8$hu$1 at ger dot gmane dot org> <1381533382 dot 4474 dot 15 dot camel at saturn>
On 2013-10-11, Daniel Helgason <dhelgason@shaw.ca> wrote:
> On Fri, 2013-10-11 at 21:48 +0000, Grant Edwards wrote:
>> I'm working with an app that uses the CYG_HAL_TABLE macros for seveal
>> different purposes. I've always thought that the "END" label was at
>> the end of the "array" of objects, such that you can iterate a table
>> like this:
>>
>>
>> for (p = __foo_TAB__; p < __foo_TAB_END__; ++p)
>> {
>> // process object pointed to by p
>> }
>>
>> But this seems not to be the case. At least for Cortex M3 targets
>> The END label is aligned on an 8-byte boundary so that there may be
>> up to 7 bytes of padding between the end of the table and the END
>> label...
>
> Yes, 8-byte alignment is the default alignment for entries in the
> tables.
>
> Check out hal/common/current/include/hal_tables.h and in particular
> CYG_HAL_TABLE_TYPE macro. That should fix the problem.
Thanks! I don't know how I missed that.
Actually I do know: it has to do with the practice of nesting
preprocessor macros 6 deep before you get to actual code.
But, I guess if it weren't for the multiple layers of misdirection,
you would end up having to use gnu binutils and gcc for building eCos
instead of being able to use any toolchain you wanted.
;)
--
Grant
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss