Aliasing issue with TAILQ on ppc64 ?

Poul-Henning Kamp phk at phk.freebsd.dk
Tue Sep 18 20:14:54 UTC 2012


In message <20120918195353.GA56160 at stack.nl>, Jilles Tjoelker writes:

>A dirty workaround is -fno-strict-aliasing but this reduces optimization
>opportunities all over the code.

Even if it works, I don't think we should mandate that for all code
using <sys/queue.h>

>An obvious fix is to make TAILQ_ENTRY and TAILQ_HEAD the same type (and
>not just structurally identical) or to add an intermediate struct which
>is the same between them.

I've tried something along those lines several times, but I have so far
not been able to make it work, without a major change to the TAILQ_*
api, which I am not prepared to push.

>However, I think the TAILQ_LAST and TAILQ_PREV macros are better
>rewritten using __containerof,

I really don't think that is an improvement, I'd prefer a typesafe
standard C solution which static checker tools like Coverity and
FlexeLint can see how works.

I suspect it would be enough to make the tqh_last and tqe_prev
pointer be volatile pointers to struct type pointers, but absent
a deeper understanding of whats actually going on I can't tell
if that would be a proper solution or merely obfuscation and
workaround.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.


More information about the freebsd-arch mailing list