Janus-gateway: Several Wcast-align warnings when cross-compiling

[aduskett]

When cross-compiling against the latest Janus (0.2.4), all throughout the build process there are numerous
Wcast-align warnings.

https://pastebin.com/tsXCZVpd

The particular architecture is an i.MX6 cortex-a9 being compiled with GCC 6.4 and using GlibC as the c library.
Not sure if it's a major issue, but it looks like it could be a prime spot for nasty memory gremlins to pop up, so I figured you might want to know.

Thanks!

Adam

[lminiero]

Never been much of an expert on this stuff, so I don't know if it can cause issues either. I'll wait for feedback on how this might be addressed in case. Anyway, I'm going on vacation in a few days so I probably won't be able to do anything about this until I come back.

[lminiero]

We didn't do anything on this since then, so I suspect master and refcount still very much exhibit the same behaviour. Again, not sure what I can do with respect to that, though. Any feedback?

[atoppi]

@aduskett would you mind sharing the procedure to enable cross compiling? I'm on Ubuntu 16.04, and simply trying make CC=arm-linux-gnueabihf-gcc does not work, because the compiler is complaining about some failed assertions in glib, probably because I have a platform specific glib installation.

[aduskett]

Hey guys; sorry I didn't respond earlier. I missed the notification.

The cross-compiling happens in BuildRoot. I have a minimal defconfig based off of glibc that you can use to test the issue with. To reproduce the issue, do the following:

• Download and extract BuildRoot
• Download the following and put it in configs/janus_defconifg (remove the .txt) janus_defconfig.txt
• Type "make janus_defconfig"
• Run "make janus-gateway"

This is a pretty minimal install of janus-gateway, but all of the extensions are supported. If you want to enable more extensions, feel free to run "make menuconfig" and go to Target packages -> Networking applications -> janus-gateway" and enable what you want.

Thanks!

Adam

[atoppi]

@aduskett that's a quite impressive tool!

I am able to recreate the warning, I'll let you know if I find something.

[aduskett]

Thanks, atoppi! I really appreciate it!

If you look at packages/janus-gateway you can also see a few other patches. They may or may not apply to master, but it's always worth taking a look!

[atoppi]

It seems like Cortex A9 is based on ARMv7, that does support unaligned memory access in its instructions set.
Indeed there are many experiences of Janus installations on embedded linux systems like RaspberryPis.
However from what I understand (_and correct me if I'm wrong_) that warning could hide a potential performance hit on these kind of architectures. The issue comes from a char* (1-byte aligned) casting to a janus_rtp_header* (struct, 4-bytes aligned). So depending on the original char* address, the access to the struct may imply multiple accesses to the memory.

[atoppi]

@aduskett after reading a lot of ARM docs, I think we can exclude any warning coming from a casting of:
1) statically allocated variables: those go in stack area, according to ARM docs they must be guaranteed to be 4-bytes or 8-bytes aligned in ARMv7.
Quoting the Procedure Call Standard for the ARM Architecture

5.2.1.1 Universal stack constraints
At all times the following basic constraints must hold:

• Stack-limit < SP <= stack-base. The stack pointer must lie within the extent of the stack.
• SP mod 4 = 0. The stack must at all times be aligned to a word boundary.

The target toolchain take care of this.

2) dynamically allocated memory with malloc: alignment specifications are implementation specific. The local standard library, in your case glibc, take care of this: malloc and similar functions in glibc always returns multiple of eight (or sixteen on 64-bit systems) addresses (cfr).

So most of those warnings is not relevant. Neither memory error, nor unaligned access, is actually happening here, at least on ARMv7.

[aduskett]

That's a relief! I really appreciate you digging into this for me. I wonder if there's an easy way to byte align the char * being cast to the struct as to suppress the warning?

[lminiero]

It's probably enough to remove -Wcast-align from Makefile.am.

[cmacq2]

Yes, all the warning says is that GCC will not be able to pack various variables as tightly together as it would like -- probably due to mismatches in sizeof which it must resolve to the nearest multiple of 4 that is sufficiently large to ensure alignment.

Actual unaligned access in ARM would cause a bus error which would be a fatal error.

[atoppi]

@aduskett you can trick the compiler in many ways using gcc attributes, builtin functions or doing a double casting passing through a void *. Take a look at __builtin_assume_aligned gcc function.
Personally, I would not recommend any of these "tricks". I'll just leave the warning there, compiling the lesser the code you need (disable all plugins and transports you do not need) and check every warning about memory alignment. If you are not sure, you can just print out the pointers values to discover if this is a false issue in your environment (hint: check the alignment by reading the trailing zeroes into the address).
The warning does exist for a reason as it could potentially lead to a crash or performance drawback and the effect is totally dependent by:

• target architecture and ABI.
• standard library.

So I think it's better to spend some time to understand what the warning is trying to say instead of just suppress it, especially while developing for not X86-machines and given the fact that you can easily extend and customize our code, so you could easily generate new sources of misaligned access issues.

That said, I think we can close the issue now. Thank you for reporting.