with full respect, I don’t think that this is right way. Moreover, I think that you papering over real problem there.
With this patch, what’s happen if someone requests any higher alignment (that actual 16) for TLS data? Or, can patched kernel run the old init (pre r324938)?

After day of digging, I’m still not sure which TLS model mips uses. Mainly which value is expected to be returned by tls_get_tp() function.
It’s clear that mips doesn’t follow Variant I of TLS standard (which require TP pointing to TCB), but it takes relaxed model of this. Something like
“The "thread pointer register" points to some fixed offset from the beginning of the TLS segment. This offset varies by arch“.

If is this true, then my change in libc/gen/tls.h has been significantly incomplete and the arch specific bits need to be implemented.

Nov 17 2017

On kernel side, we calculate TLS size (td->td_md.md_tls_tcb_offset) in several places used by static & dynamic at same time. So if we roundup2 it, /sbin/init works, but /bin/sh fails.
As of now, I suppose that current fix is the only quick solution :\

Is this needed at all after rS325364? We should now be respecting the alignment of the PT_TLS section. If the PT_TLS section isn't correctly aligned then fixing that is the right answer rather than trashing the ABI.

Generally speaking, I'm happy with patch. The only thing I worry is CD9660 image (inspired by ZRouter) vs. UFS1 zipped image (inspired by freebsd-wifi-build). This patch is based on CD9660 and it can be committed, but in future it will be nice to support both image types.

Nov 17 2016

@yamori813_yahoo.co.jp , could you please test this commit? It's slightly different from your version, I've checked compilation and i want to be sure that nothing from functional part is broken. Thanks in advance