This is the mail archive of the
mailing list for the eCos project.
HAL_ENABLE_INTERRUPTS a memory barrier?
- From: Stanislav Meduna <stano at meduna dot org>
- To: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Fri, 04 Feb 2011 11:13:33 +0100
- Subject: [ECOS] HAL_ENABLE_INTERRUPTS a memory barrier?
the HAL_ENABLE_INTERRUPTS for ARM is defined as
#define HAL_ENABLE_INTERRUPTS() \
asm volatile ( \
"mrs r3,cpsr;" \
"bic r3,r3,#0xC0;" \
"msr cpsr,r3" \
: "r3" \
I am not an expert in gcc, but shouldn't this be a reorder
barrier too, adding "memory" to the clobber list? If
I understand this correctly, the compiler is free to cache
values in registers across these instructions, even when
not optimizing. The volatile keyword only specifies
that the block cannot be moved. If the interrupt happens
right in the next instruction, this can have disastrous
results. Or am I overlooking something?
I am investigating a weird corruption where - the
inconsistent alarm list from my previous mail was
followed by "DSR posted but post count is zero"
assertion in Cyg_Interrupt::call_pending_DSRs_inner.
I can't see how this can happen except for
intr->dsr_count = 0 being deferred across
HAL_RESTORE_INTERRUPTS around line 190 in intr.cxx
and the same interrupt doing post_dsr right there.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss