Date: Tue, 10 Mar 2015 00:27:18 +0000 From: "meloun-miracle-cz (Michal Meloun)" <phabric-noreply@FreeBSD.org> To: freebsd-arm@freebsd.org Subject: [Differential] [Commented On] D2017: Allow to disable alignment faults in the kernel configuration file Message-ID: <e18005183064d763b9950aad5b22bcb0@localhost.localdomain> In-Reply-To: <differential-rev-PHID-DREV-phrk75eo7uo5meyd5xay-req@FreeBSD.org> References: <differential-rev-PHID-DREV-phrk75eo7uo5meyd5xay-req@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
meloun-miracle-cz added a comment. > **Jakub Palider wrote:** >Yes, I think I understand your reasoning, but you refer to a more >generic problem, related to CPU settings vs compiler code generation. >Let me show a more concrete example. Below is an extract from fault when >there is no ARM32_DISABLE_ALIGNMENT_FAULTS set. > >r7=a5b60b36a >Stopped at tcp_input+0x738: ldr r0, [r7, #0x004] > >Here, we can see instruction (LDR) which *does* operate on unaligned >addresses, so I assume compiler was clever enough not to use any of >those "forbidden" instructions (e.g. LDMIA/STMIA). This resolution is invalid, imho. The kernel is compiled with “-mno-unaligned-access”, and if everything is in order, the compiler cannot generate any unaligned access. The fault in tcp_input() indicates problem in code, compiler evidently assumes aligned address here. Due to this (incorrect) assumption compiler is free to generate any instruction (LDM/STM including). Or I miss something? Enabling of unaligned access is big win for network code. But this case is evident papering over real problem. And this problem must be solved first. REVISION DETAIL https://reviews.freebsd.org/D2017 To: zbb, ian, andrew, imp Cc: meloun-miracle-cz, freebsd-arm
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e18005183064d763b9950aad5b22bcb0>