[Freeswitch-dev] Freeswitch on ARM, Memory alignment issues

[M D]

On Tue, 18 Jan 2011 15:40:40 -0500
Michael Jerris <mike at jerris.com> wrote:

> 
> On Jan 18, 2011, at 2:42 PM, M D wrote:
> 
> > On Tue, 18 Jan 2011 12:54:53 -0500
> > Michael Jerris <mike at jerris.com> wrote:
> > 
> > In general, should I conclude that this issue has not been
> > encountered before?
> 
> This has certainly been encountered before, on different platforms,
> including arm.  I suspect this is a toolchain issue more than
> anything in this case as we have worked on arm for quite some time.
Would it be possible to know which tuple works? I.e. binutils,gcc,
libc (glibc or uclibc). At the moment I am trying to build different
combinations of the toolchain to see if I can isolate a working
version. What is the best way to share a testcase with the list?

> > I expected that the original code would be aligned too. It just
> > wasn't, atleast with gcc 4.3.3 + Code Sourcery enhancements. In gcc
> > 4.4.5 ( I think, I don't have access to my development machine at
> > the moment.) using the switch -falign-functions did align the
> > buffer buf at a 32-bit boundary. Of course align-functions does not
> > ensure that all uint8_t buffers would be aligned. 
> 
> Is there a gcc arg that will make this work?  If so we can test for
> that being available and use it when it is.
I could not find one. I think I understand why gcc would not align the
uint8_t array to a 16/32-bit boundary: The alignment is data type
dependent, and since uint8_t is 8-bits, there is no need to align it
with a 32-bit boundary.

For what it is worth, malloc documentation suggests that it will return
memory suitably aligned for **any** variable type, which means that it
should work correctly on all platforms. I am not sure if the run-time
overhead would be prohibitively high.

Thanks for your input on all this.
-m