* kernel miscompilation with gcc 4.8 for ARMv5 @ 2013-07-10 11:36 Enrico Scholz 2013-07-10 12:34 ` Enrico Scholz 0 siblings, 1 reply; 11+ messages in thread From: Enrico Scholz @ 2013-07-10 11:36 UTC (permalink / raw) To: openembedded-core Hi, is it expected that recent gcc 4.8[1] compiles the kernel correctly? Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here 100% at early boot with [ 0.404750] Unable to handle kernel paging request at virtual address 00210020 [ 0.412468] pgd = c0004000 [ 0.415187] [00210020] *pgd=00000000 [ 0.418812] Internal error: Oops: 5 [#1] PREEMPT ARM [ 0.423781] CPU: 0 Not tainted (3.8.13.ipan4 #1) [ 0.428781] PC is at kmem_cache_alloc+0x44/0xcc [ 0.433375] LR is at con_insert_unipair+0xa4/0xf0 [ 0.438093] pc : [<c00a6d7c>] lr : [<c02dc654>] psr: 20000053 (this is a similar error as described in [2]). Enabling heavy memory debugging shows [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) [ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) [ 0.000000] .text : 0xc0008000 - 0xc0436000 (4280 kB) [ 0.000000] .init : 0xc0436000 - 0xc046a000 ( 208 kB) [ 0.000000] .data : 0xc046a000 - 0xc049bff8 ( 200 kB) [ 0.000000] .bss : 0xc049c01c - 0xc0511680 ( 470 kB) [ 0.000000] ============================================================================= [ 0.000000] BUG kmem_cache_node (Not tainted): Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] INFO: 0xc78010fc-0xc78010ff. First byte 0x5a instead of 0xbb [ 0.000000] INFO: Slab 0xc0620024 objects=18 used=18 fp=0x (null) flags=0x0080 [ 0.000000] INFO: Object 0xc78010e0 @offset=224 fp=0xc78011c0 [ 0.000000] [ 0.000000] Bytes b4 c78010d0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ [ 0.000000] Object c78010e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk [ 0.000000] Object c78010f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 5a kkkkkkkkkkkZ [ 0.000000] Redzone c78010fc: 5a 5a 5a 5a ZZZZ [ 0.000000] Padding c78011a4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ [ 0.000000] Padding c78011b4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ [ 0.000000] Backtrace: for the 3.4.52 kernel. Compiling mm/slub.o with -O1 fixes *these* problems but there happen other crashes later. A kernel compiled for an ARMv7 platform (OMAP4, kernel 3.4.43) seems to work (although there might be enabled other kernel options). Are these problems resp. fixes known? Enrico Footnotes: [1] from 4f5009dcbbeb27bdf5dcaebb3b457fecef410ebe [2] https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1178847 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kernel miscompilation with gcc 4.8 for ARMv5 2013-07-10 11:36 kernel miscompilation with gcc 4.8 for ARMv5 Enrico Scholz @ 2013-07-10 12:34 ` Enrico Scholz 2013-07-10 13:15 ` Mike Looijmans ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Enrico Scholz @ 2013-07-10 12:34 UTC (permalink / raw) To: openembedded-core Enrico Scholz <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org> writes: > is it expected that recent gcc 4.8[1] compiles the kernel correctly? > Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here > 100% at early boot with Applying two upstream kernel commits 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations) and 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset fix) seem to fix the problem for me. Enrico ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kernel miscompilation with gcc 4.8 for ARMv5 2013-07-10 12:34 ` Enrico Scholz @ 2013-07-10 13:15 ` Mike Looijmans 2013-07-10 13:25 ` Mark Hatle 2013-07-10 13:57 ` Bruce Ashfield 2013-07-19 5:39 ` Holger Freyther 2 siblings, 1 reply; 11+ messages in thread From: Mike Looijmans @ 2013-07-10 13:15 UTC (permalink / raw) To: openembedded-core On 07/10/2013 02:34 PM, Enrico Scholz wrote: > Enrico Scholz > <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org> > writes: > >> is it expected that recent gcc 4.8[1] compiles the kernel correctly? >> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here >> 100% at early boot with > > Applying two upstream kernel commits > 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix > memset-related crashes caused by recent GCC (4.7.2) optimizations) and > 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset > fix) seem to fix the problem for me. > I encountered a compilation problem for MIPS kernels (version 3.3 and below) with the new GCC compiler: arch/mips/mm/page.c:89:6: error: 'clear_page' alias in between function and variable is not supported void clear_page(void *page) __attribute__((alias("clear_page_array"))); ^ arch/mips/mm/page.c:84:12: error: 'clear_page_array' aliased declaration [-Werror] static u32 clear_page_array[0x120 / 4]; ^ arch/mips/mm/page.c:108:6: error: 'copy_page' alias in between function and variable is not supported void copy_page(void *to, void *from) __attribute__((alias("copy_page_array"))); ^ arch/mips/mm/page.c:102:12: error: 'copy_page_array' aliased declaration [-Werror] static u32 copy_page_array[0x540 / 4]; So I'll probably have to go and look for backports to apply here. Anyone happen to come across this one already? (Looking in the git history for that file suggests applying c022630633624a75b3b58f43dd3c6cc896a56cff from upstream) A 3.8 kernel is running just fine with gcc 4.8. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kernel miscompilation with gcc 4.8 for ARMv5 2013-07-10 13:15 ` Mike Looijmans @ 2013-07-10 13:25 ` Mark Hatle 2013-07-11 5:38 ` Mike Looijmans 0 siblings, 1 reply; 11+ messages in thread From: Mark Hatle @ 2013-07-10 13:25 UTC (permalink / raw) To: openembedded-core On 7/10/13 8:15 AM, Mike Looijmans wrote: > On 07/10/2013 02:34 PM, Enrico Scholz wrote: >> Enrico Scholz >> <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org> >> writes: >> >>> is it expected that recent gcc 4.8[1] compiles the kernel correctly? >>> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here >>> 100% at early boot with >> >> Applying two upstream kernel commits >> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix >> memset-related crashes caused by recent GCC (4.7.2) optimizations) and >> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset >> fix) seem to fix the problem for me. >> > > I encountered a compilation problem for MIPS kernels (version 3.3 and > below) with the new GCC compiler: > > > arch/mips/mm/page.c:89:6: error: 'clear_page' alias in between > function and variable is not supported > void clear_page(void *page) __attribute__((alias("clear_page_array"))); > ^ > arch/mips/mm/page.c:84:12: error: 'clear_page_array' aliased declaration > [-Werror] > static u32 clear_page_array[0x120 / 4]; > ^ > arch/mips/mm/page.c:108:6: error: 'copy_page' alias in between function > and variable is not supported > void copy_page(void *to, void *from) > __attribute__((alias("copy_page_array"))); > ^ > arch/mips/mm/page.c:102:12: error: 'copy_page_array' aliased declaration > [-Werror] > static u32 copy_page_array[0x540 / 4]; > > > So I'll probably have to go and look for backports to apply here. Anyone > happen to come across this one already? > (Looking in the git history for that file suggests applying > c022630633624a75b3b58f43dd3c6cc896a56cff from upstream) > > A 3.8 kernel is running just fine with gcc 4.8. The following commit fixed the issue in 3.4. I assume it'll work in other versions. kernel.org commit: c022630633624a75b3b58f43dd3c6cc896a56cff http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c022630633624a75b3b58f43dd3c6cc896a56cff > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kernel miscompilation with gcc 4.8 for ARMv5 2013-07-10 13:25 ` Mark Hatle @ 2013-07-11 5:38 ` Mike Looijmans 0 siblings, 0 replies; 11+ messages in thread From: Mike Looijmans @ 2013-07-11 5:38 UTC (permalink / raw) To: openembedded-core On 07/10/2013 03:25 PM, Mark Hatle wrote: > On 7/10/13 8:15 AM, Mike Looijmans wrote: >> On 07/10/2013 02:34 PM, Enrico Scholz wrote: >>> Enrico Scholz >>> <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org> >>> writes: >>> >>>> is it expected that recent gcc 4.8[1] compiles the kernel correctly? >>>> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail >>>> here >>>> 100% at early boot with >>> >>> Applying two upstream kernel commits >>> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix >>> memset-related crashes caused by recent GCC (4.7.2) optimizations) and >>> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset >>> fix) seem to fix the problem for me. >>> >> >> I encountered a compilation problem for MIPS kernels (version 3.3 and >> below) with the new GCC compiler: >> >> >> arch/mips/mm/page.c:89:6: error: 'clear_page' alias in between >> function and variable is not supported >> void clear_page(void *page) __attribute__((alias("clear_page_array"))); >> ^ >> arch/mips/mm/page.c:84:12: error: 'clear_page_array' aliased declaration >> [-Werror] >> static u32 clear_page_array[0x120 / 4]; >> ^ >> arch/mips/mm/page.c:108:6: error: 'copy_page' alias in between function >> and variable is not supported >> void copy_page(void *to, void *from) >> __attribute__((alias("copy_page_array"))); >> ^ >> arch/mips/mm/page.c:102:12: error: 'copy_page_array' aliased declaration >> [-Werror] >> static u32 copy_page_array[0x540 / 4]; >> >> >> So I'll probably have to go and look for backports to apply here. Anyone >> happen to come across this one already? >> (Looking in the git history for that file suggests applying >> c022630633624a75b3b58f43dd3c6cc896a56cff from upstream) >> >> A 3.8 kernel is running just fine with gcc 4.8. > > The following commit fixed the issue in 3.4. I assume it'll work in > other versions. > > kernel.org commit: c022630633624a75b3b58f43dd3c6cc896a56cff > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c022630633624a75b3b58f43dd3c6cc896a56cff Indeed, patching that into the kernels fixed it. Mike. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kernel miscompilation with gcc 4.8 for ARMv5 2013-07-10 12:34 ` Enrico Scholz 2013-07-10 13:15 ` Mike Looijmans @ 2013-07-10 13:57 ` Bruce Ashfield 2013-07-10 14:30 ` Enrico Scholz 2013-07-14 4:58 ` Bruce Ashfield 2013-07-19 5:39 ` Holger Freyther 2 siblings, 2 replies; 11+ messages in thread From: Bruce Ashfield @ 2013-07-10 13:57 UTC (permalink / raw) To: Enrico Scholz; +Cc: Patches and discussions about the oe-core layer On Wed, Jul 10, 2013 at 9:34 AM, Enrico Scholz <enrico.scholz@sigma-chemnitz.de> wrote: > Enrico Scholz > <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org> > writes: > >> is it expected that recent gcc 4.8[1] compiles the kernel correctly? >> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here >> 100% at early boot with > > Applying two upstream kernel commits > 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix > memset-related crashes caused by recent GCC (4.7.2) optimizations) and > 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset > fix) seem to fix the problem for me. Correct. Those are the same commits you'll see on linux-yocto-3.8, we've been soaking them for a while. I was waiting for LTSI and -stable to pick up the changes before updating linux-yocto-3.4, but that hasn't happened yet. If you are using linux-yocto-3.4 and can confirm that it boots for you with those patches, I can stage them in my tree while I wait for them to loop around. Cheers, Bruce > > > > Enrico > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kernel miscompilation with gcc 4.8 for ARMv5 2013-07-10 13:57 ` Bruce Ashfield @ 2013-07-10 14:30 ` Enrico Scholz 2013-07-10 16:35 ` Bruce Ashfield 2013-07-14 4:58 ` Bruce Ashfield 1 sibling, 1 reply; 11+ messages in thread From: Enrico Scholz @ 2013-07-10 14:30 UTC (permalink / raw) To: openembedded-core; +Cc: Bruce Ashfield Bruce Ashfield <bruce.ashfield-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes: >> Applying two upstream kernel commits >> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix >> memset-related crashes caused by recent GCC (4.7.2) optimizations) and >> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset >> fix) seem to fix the problem for me. > > Correct. Those are the same commits you'll see on linux-yocto-3.8, > we've been soaking them for a while. I was waiting for LTSI and -stable > to pick up the changes before updating linux-yocto-3.4, but that hasn't > happened yet. > > If you are using linux-yocto-3.4 and can confirm that it boots for you > with those patches, Sorry, I am using a more or less vanilla 3.4 kernel. Patches fix the problem there (device boots) and (after knowing about them) the problematic code is easy to spot: $ arm-linux-gnueabi-objdump -d mm/slub.o 000014c4 <init_object>: ... 14fc: e1a00001 mov r0, r1 1500: e3a0106b mov r1, #107 ; 0x6b 1504: ebfffffe bl 0 <memset> 1508: e1a03000 mov r3, r0 <<<<<<< 150c: e5942010 ldr r2, [r4, #16] 1510: e3e0105a mvn r1, #90 ; 0x5a 1514: e0832002 add r2, r3, r2 1518: e5421001 strb r1, [r2, #-1] With unpatched memset, 'r0' points to end of buffer. Enrico ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kernel miscompilation with gcc 4.8 for ARMv5 2013-07-10 14:30 ` Enrico Scholz @ 2013-07-10 16:35 ` Bruce Ashfield 0 siblings, 0 replies; 11+ messages in thread From: Bruce Ashfield @ 2013-07-10 16:35 UTC (permalink / raw) To: Enrico Scholz Cc: Bruce Ashfield, Patches and discussions about the oe-core layer On Wed, Jul 10, 2013 at 11:30 AM, Enrico Scholz <enrico.scholz@sigma-chemnitz.de> wrote: > Bruce Ashfield <bruce.ashfield-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > writes: > >>> Applying two upstream kernel commits >>> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix >>> memset-related crashes caused by recent GCC (4.7.2) optimizations) and >>> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset >>> fix) seem to fix the problem for me. >> >> Correct. Those are the same commits you'll see on linux-yocto-3.8, >> we've been soaking them for a while. I was waiting for LTSI and -stable >> to pick up the changes before updating linux-yocto-3.4, but that hasn't >> happened yet. >> >> If you are using linux-yocto-3.4 and can confirm that it boots for you >> with those patches, > > Sorry, I am using a more or less vanilla 3.4 kernel. Patches fix > the problem there (device boots) and (after knowing about them) the > problematic code is easy to spot: No worries. I can spot the fix, since we already did this for the 3.8 kernel. I was just no where near my targets at the moment .. and if I had an independent report that things boot, I'd go ahead and push my 3.8 fixes (ported to 3.4) .. which I may do anyway, since I can drop them when they cycle through -stable and LTSI. Cheers, Bruce > > $ arm-linux-gnueabi-objdump -d mm/slub.o > > 000014c4 <init_object>: > ... > 14fc: e1a00001 mov r0, r1 > 1500: e3a0106b mov r1, #107 ; 0x6b > 1504: ebfffffe bl 0 <memset> > 1508: e1a03000 mov r3, r0 <<<<<<< > 150c: e5942010 ldr r2, [r4, #16] > 1510: e3e0105a mvn r1, #90 ; 0x5a > 1514: e0832002 add r2, r3, r2 > 1518: e5421001 strb r1, [r2, #-1] > > With unpatched memset, 'r0' points to end of buffer. > > > Enrico > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kernel miscompilation with gcc 4.8 for ARMv5 2013-07-10 13:57 ` Bruce Ashfield 2013-07-10 14:30 ` Enrico Scholz @ 2013-07-14 4:58 ` Bruce Ashfield 1 sibling, 0 replies; 11+ messages in thread From: Bruce Ashfield @ 2013-07-14 4:58 UTC (permalink / raw) To: Enrico Scholz; +Cc: Patches and discussions about the oe-core layer On Wed, Jul 10, 2013 at 9:57 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > On Wed, Jul 10, 2013 at 9:34 AM, Enrico Scholz > <enrico.scholz@sigma-chemnitz.de> wrote: >> Enrico Scholz >> <enrico.scholz-wttK6gPy29v+Hn7q9Vec/7NAH6kLmebB@public.gmane.org> >> writes: >> >>> is it expected that recent gcc 4.8[1] compiles the kernel correctly? >>> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here >>> 100% at early boot with >> >> Applying two upstream kernel commits >> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix >> memset-related crashes caused by recent GCC (4.7.2) optimizations) and >> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset >> fix) seem to fix the problem for me. > > Correct. Those are the same commits you'll see on linux-yocto-3.8, we've been > soaking them for a while. I was waiting for LTSI and -stable to pick > up the changes > before updating linux-yocto-3.4, but that hasn't happened yet. > > If you are using linux-yocto-3.4 and can confirm that it boots for you > with those patches, > I can stage them in my tree while I wait for them to loop around. > Heh. Clearly I had vacation brain when I wrote this .. I merged and pushed the two ARM gcc 4.8 fixes on June 20th, at the same time I was fixing 3.8. :) Cheers, Bruce > Cheers, > > Bruce > >> >> >> >> Enrico >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end" -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kernel miscompilation with gcc 4.8 for ARMv5 2013-07-10 12:34 ` Enrico Scholz 2013-07-10 13:15 ` Mike Looijmans 2013-07-10 13:57 ` Bruce Ashfield @ 2013-07-19 5:39 ` Holger Freyther 2013-07-19 11:24 ` Phil Blundell 2 siblings, 1 reply; 11+ messages in thread From: Holger Freyther @ 2013-07-19 5:39 UTC (permalink / raw) To: openembedded-core Enrico Scholz <enrico.scholz@...> writes: Good Morning, > Applying two upstream kernel commits > 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix > memset-related crashes caused by recent GCC (4.7.2) optimizations) and > 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset > fix) seem to fix the problem for me. I am in a similar situation with ARMv5. My 3.2.48 kernel randomly crashed inside namei.c:do_lookup when de-referencing a bogus address and after upgrading to 3.4.53 I do see crashes in the tcpv4 receive path. Compiling my kernel with GCC 4.6.3 appears to produce a working one. The output of the oops can be seen here[1], from what I see I am entering this path[2] and besides the if (sk2) { sk = sk2; goto process; } ... process: if (sk->sk_state == TCP_TIME_WAIT) goto do_time_wait; ... will crash on the above line. Compiling tcp_ipv4.c with GCC4.6.3 and re-linking doesn't appear to fix the problem but maybe I made another mistake. Do you guys have an idea on how to proceed? [1] http://paste.lisp.org/display/138095 [2] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/ipv 4/tcp_ipv4.c?id=v3.4#n1833 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: kernel miscompilation with gcc 4.8 for ARMv5 2013-07-19 5:39 ` Holger Freyther @ 2013-07-19 11:24 ` Phil Blundell 0 siblings, 0 replies; 11+ messages in thread From: Phil Blundell @ 2013-07-19 11:24 UTC (permalink / raw) To: Holger Freyther; +Cc: openembedded-core On Fri, 2013-07-19 at 05:39 +0000, Holger Freyther wrote: > will crash on the above line. Compiling tcp_ipv4.c with GCC4.6.3 > and re-linking doesn't appear to fix the problem but maybe I made > another mistake. If your analysis of the path that leads up to the crash is correct then it sounds like the bug is probably in inet_hashtables.c not tcp_ipv4.c. Does it help if you recompile that one file with the older GCC and re-link? p. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-07-19 11:24 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-07-10 11:36 kernel miscompilation with gcc 4.8 for ARMv5 Enrico Scholz 2013-07-10 12:34 ` Enrico Scholz 2013-07-10 13:15 ` Mike Looijmans 2013-07-10 13:25 ` Mark Hatle 2013-07-11 5:38 ` Mike Looijmans 2013-07-10 13:57 ` Bruce Ashfield 2013-07-10 14:30 ` Enrico Scholz 2013-07-10 16:35 ` Bruce Ashfield 2013-07-14 4:58 ` Bruce Ashfield 2013-07-19 5:39 ` Holger Freyther 2013-07-19 11:24 ` Phil Blundell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.