Jon Masters
2012-01-30 06:56:41 UTC
Greetings,
I have been trying to help diagnose a failure to build in the icu
package for Fedora on ARM systems, with gcc 4.7. I should very much like
to know the answer to a few questions, so that I can help fix this. I
would like to say at the outset that I believe I am a reasonably
competent programmer, but I am not (yet perhaps) a gcc hacker, though I
certainly enjoy any such opportunity to get to know its internals more.
I understand more of the theory than the implementation of compilers :)
The __sync_synchronize "legacy" sync function is intended to be used to
perform an expensive data memory barrier operation. It is defined within
libgcc in such a way that I *believe* means that, on most architectures,
it is replaced with an inline assembly code emitted that performs a sync
operation. On ARM, and some other architectures with mixed ISAs wherein
there may not be a sync function nor one way to do this, this function
(__sync_synchronize) can be a real function call. In that case, it might
cause inline assembly generation, or e.g. call a kernel VDSO helper.
The icu package contains a direct call to __sync_sychronize, especially
in the iotest test cases. I believe that this compiles fine on x86
because there is no function call. However, on ARM, the code fails to
link because the __sync_synchronize function is HIDDEN and not exported
(or so goes my understanding - is that correct?). I am drawing a blank,
though, on how this differs from earlier versions of gcc such as 4.6
(aside from a slight difference in the macro used to make it available),
and whether it is indeed the case that this function should be made
available within libgcc for direct linking? In other words, I do not
know whether there is a bug here in gcc or whether icu needs changing.
It seems that there are newer, less expensive sync operations that
perhaps ought to be used instead, but I don't have the full context.
Please forgive my lack of understanding of gcc intrinsics, and atomics.
I would very much like to learn more about the internal implementation
and I look forward to whatever information you can share with me. If you
would like more information, I can happily provide it in the morning. It
is very late here, but I wanted to start this thread asap. We are trying
to fix icu so that we can continue to build Fedora 17 for ARM systems.
Thanks very much,
Jon.
I have been trying to help diagnose a failure to build in the icu
package for Fedora on ARM systems, with gcc 4.7. I should very much like
to know the answer to a few questions, so that I can help fix this. I
would like to say at the outset that I believe I am a reasonably
competent programmer, but I am not (yet perhaps) a gcc hacker, though I
certainly enjoy any such opportunity to get to know its internals more.
I understand more of the theory than the implementation of compilers :)
The __sync_synchronize "legacy" sync function is intended to be used to
perform an expensive data memory barrier operation. It is defined within
libgcc in such a way that I *believe* means that, on most architectures,
it is replaced with an inline assembly code emitted that performs a sync
operation. On ARM, and some other architectures with mixed ISAs wherein
there may not be a sync function nor one way to do this, this function
(__sync_synchronize) can be a real function call. In that case, it might
cause inline assembly generation, or e.g. call a kernel VDSO helper.
The icu package contains a direct call to __sync_sychronize, especially
in the iotest test cases. I believe that this compiles fine on x86
because there is no function call. However, on ARM, the code fails to
link because the __sync_synchronize function is HIDDEN and not exported
(or so goes my understanding - is that correct?). I am drawing a blank,
though, on how this differs from earlier versions of gcc such as 4.6
(aside from a slight difference in the macro used to make it available),
and whether it is indeed the case that this function should be made
available within libgcc for direct linking? In other words, I do not
know whether there is a bug here in gcc or whether icu needs changing.
It seems that there are newer, less expensive sync operations that
perhaps ought to be used instead, but I don't have the full context.
Please forgive my lack of understanding of gcc intrinsics, and atomics.
I would very much like to learn more about the internal implementation
and I look forward to whatever information you can share with me. If you
would like more information, I can happily provide it in the morning. It
is very late here, but I wanted to start this thread asap. We are trying
to fix icu so that we can continue to build Fedora 17 for ARM systems.
Thanks very much,
Jon.