* [Xenomai-core] Problem with gcc-4.5.1 @ 2010-12-07 11:44 Anders Blomdell 2010-12-07 11:51 ` Gilles Chanteperdrix 0 siblings, 1 reply; 12+ messages in thread From: Anders Blomdell @ 2010-12-07 11:44 UTC (permalink / raw) To: xenomai@xenomai.org [-- Attachment #1: Type: text/plain, Size: 663 bytes --] When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails with the attached kernel OOPS, a notable difference between the 4.5.1 compiled version and a working one built with gcc-4.4.4 on the same system with the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not inlined, is this anybody has seen before? Regards Anders Blomdell -- Anders Blomdell Email: anders.blomdell@domain.hid Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden [-- Attachment #2: oops --] [-- Type: text/plain, Size: 1894 bytes --] BUG: unable to handle kernel NULL pointer dereference at 00000008 IP: [<fbf25804>] __rthal_x86_nodiv_ullimd+0x5c/0x74 [xeno_nucleus] *pdpt = 0000000001d91001 *pde = 0000000000000000 Oops: 0000 [#1] SMP last sysfs file: /sys/module/microcode/initstate Modules linked in: xeno_nucleus(+) e1000 snd_timer snd e1000e soundcore iTCO_wdt i2c_i801 serio_raw iTCO_vendor_support snd_page_alloc microcode(+) pcspkr pata_acpi firewire_ohci ata_generic firewire_core crc_itu_t pata_marvell nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core Pid: 519, comm: modprobe Not tainted 2.6.35.7_xenomai-2.5.5.2_rtnet-39f7fcf #1 DP35DP/ EIP: 0060:[<fbf25804>] EFLAGS: 00010246 CPU: 0 EIP is at __rthal_x86_nodiv_ullimd+0x5c/0x74 [xeno_nucleus] EAX: 00000000 EBX: b36c048c ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: c1ef1f34 ESP: c1ef1f18 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 519, ti=c1ef0000 task=c1e04080 task.ti=c1ef0000) I-pipe domain Linux Stack: 00000000 00000000 665d7cba b36c048c 00000000 b36c048c 665d7cba c1ef1f54 <0> fbf25887 b36c048c 665d7cba 00000002 00000001 00000004 665d7cba c1ef1f60 <0> fbf25a3f 00000000 c1ef1f84 fbcaf215 00000000 1194d800 00000001 3b9aca00 Call Trace: [<fbf25887>] ? xnarch_ns_to_tsc+0x34/0x4a [xeno_nucleus] [<fbf25a3f>] ? xnarch_calibrate_sched+0x1a/0xf2 [xeno_nucleus] [<fbcaf215>] ? __xeno_sys_init+0x189/0x2fd [xeno_nucleus] [<fbcaf08c>] ? __xeno_sys_init+0x0/0x2fd [xeno_nucleus] [<c0401263>] ? do_one_initcall+0x62/0x16f [<c046843c>] ? sys_init_module+0x7f/0x19d [<c040299d>] ? sysenter_do_call+0x12/0x16 Code: f0 89 d1 d1 e0 83 d1 00 83 d6 00 83 d7 00 8b 45 e4 f7 65 f0 01 c1 11 d6 83 d7 00 8b 45 e8 f7 65 ec 01 c1 11 d6 83 d7 00 8b 45 e8 <f7> 67 08 01 f0 11 d7 8b 55 e4 0f af 57 08 01 fa 83 c4 10 5b 5e EIP: [<fbf25804>] __rthal_x86_nodiv_ullimd+0x5c/0x74 [xeno_nucleus] SS:ESP 0068:c1ef1f18 CR2: 0000000000000008 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-07 11:44 [Xenomai-core] Problem with gcc-4.5.1 Anders Blomdell @ 2010-12-07 11:51 ` Gilles Chanteperdrix 2010-12-07 11:57 ` Gilles Chanteperdrix 2010-12-07 11:58 ` Anders Blomdell 0 siblings, 2 replies; 12+ messages in thread From: Gilles Chanteperdrix @ 2010-12-07 11:51 UTC (permalink / raw) To: Anders Blomdell; +Cc: xenomai@xenomai.org Anders Blomdell wrote: > When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 > 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails with the > attached kernel OOPS, a notable difference between the 4.5.1 compiled > version and a working one built with gcc-4.4.4 on the same system with > the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not > inlined, is this anybody has seen before? No, that is new, we need to see the disassembly of __rthal_x86_nodiv_ullimd -- Gilles. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-07 11:51 ` Gilles Chanteperdrix @ 2010-12-07 11:57 ` Gilles Chanteperdrix 2010-12-07 11:58 ` Anders Blomdell 1 sibling, 0 replies; 12+ messages in thread From: Gilles Chanteperdrix @ 2010-12-07 11:57 UTC (permalink / raw) To: Anders Blomdell; +Cc: xenomai@xenomai.org Gilles Chanteperdrix wrote: > Anders Blomdell wrote: >> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 >> 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails with the >> attached kernel OOPS, a notable difference between the 4.5.1 compiled >> version and a working one built with gcc-4.4.4 on the same system with >> the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not >> inlined, is this anybody has seen before? > > No, that is new, we need to see the disassembly of __rthal_x86_nodiv_ullimd > We would also need to know what were the arguments passed to this function which cause the crash to happen. -- Gilles. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-07 11:51 ` Gilles Chanteperdrix 2010-12-07 11:57 ` Gilles Chanteperdrix @ 2010-12-07 11:58 ` Anders Blomdell 2010-12-07 12:09 ` Gilles Chanteperdrix 1 sibling, 1 reply; 12+ messages in thread From: Anders Blomdell @ 2010-12-07 11:58 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote: > Anders Blomdell wrote: >> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 >> 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails with the >> attached kernel OOPS, a notable difference between the 4.5.1 compiled >> version and a working one built with gcc-4.4.4 on the same system with >> the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not >> inlined, is this anybody has seen before? > > No, that is new, we need to see the disassembly of __rthal_x86_nodiv_ullimd objdump -S: static inline __attribute__((const)) unsigned long long __rthal_x86_nodiv_ullimd(const unsigned long long op, const unsigned long long frac, unsigned integ) { e7a8: 55 push %ebp e7a9: 89 e5 mov %esp,%ebp e7ab: 57 push %edi e7ac: 56 push %esi e7ad: 53 push %ebx e7ae: 83 ec 10 sub $0x10,%esp e7b1: 8d 7d 08 lea 0x8(%ebp),%edi e7b4: e8 fc ff ff ff call e7b5 <__rthal_x86_nodiv_ullimd+0xd> e7b9: 8b 1f mov (%edi),%ebx e7bb: 8b 4f 04 mov 0x4(%edi),%ecx register unsigned rm __asm__("esi"); register unsigned rh __asm__("edi"); unsigned fracl, frach, opl, oph; register unsigned long long t; __rthal_u64tou32(op, oph, opl); e7be: 89 45 e8 mov %eax,-0x18(%ebp) __rthal_u64tou32(frac, frach, fracl); e7c1: 89 5d f0 mov %ebx,-0x10(%ebp) register unsigned rm __asm__("esi"); register unsigned rh __asm__("edi"); unsigned fracl, frach, opl, oph; register unsigned long long t; __rthal_u64tou32(op, oph, opl); e7c4: 89 55 e4 mov %edx,-0x1c(%ebp) __rthal_u64tou32(frac, frach, fracl); e7c7: 89 4d ec mov %ecx,-0x14(%ebp) __asm__ ("mov %[oph], %%eax\n\t" e7ca: 8b 45 e4 mov -0x1c(%ebp),%eax e7cd: f7 65 ec mull -0x14(%ebp) e7d0: 89 c6 mov %eax,%esi e7d2: 89 d7 mov %edx,%edi e7d4: 8b 45 e8 mov -0x18(%ebp),%eax e7d7: f7 65 f0 mull -0x10(%ebp) e7da: 89 d1 mov %edx,%ecx e7dc: d1 e0 shl %eax e7de: 83 d1 00 adc $0x0,%ecx e7e1: 83 d6 00 adc $0x0,%esi e7e4: 83 d7 00 adc $0x0,%edi e7e7: 8b 45 e4 mov -0x1c(%ebp),%eax e7ea: f7 65 f0 mull -0x10(%ebp) e7ed: 01 c1 add %eax,%ecx e7ef: 11 d6 adc %edx,%esi e7f1: 83 d7 00 adc $0x0,%edi e7f4: 8b 45 e8 mov -0x18(%ebp),%eax e7f7: f7 65 ec mull -0x14(%ebp) e7fa: 01 c1 add %eax,%ecx e7fc: 11 d6 adc %edx,%esi e7fe: 83 d7 00 adc $0x0,%edi e801: 8b 45 e8 mov -0x18(%ebp),%eax e804: f7 67 08 mull 0x8(%edi) e807: 01 f0 add %esi,%eax e809: 11 d7 adc %edx,%edi e80b: 8b 55 e4 mov -0x1c(%ebp),%edx e80e: 0f af 57 08 imul 0x8(%edi),%edx e812: 01 fa add %edi,%edx : [opl]"m"(opl), [oph]"m"(oph), [fracl]"m"(fracl), [frach]"m"(frach), [integ]"m"(integ) : "cc"); return t; } e814: 83 c4 10 add $0x10,%esp e817: 5b pop %ebx e818: 5e pop %esi e819: 5f pop %edi e81a: 5d pop %ebp e81b: c3 ret But us I said, in the working version, the code seems to be inlined everywhere. Should I send the two object modules as well (probably as a private message?). /Anders -- Anders Blomdell Email: anders.blomdell@domain.hid Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-07 11:58 ` Anders Blomdell @ 2010-12-07 12:09 ` Gilles Chanteperdrix 2010-12-07 14:14 ` Anders Blomdell 0 siblings, 1 reply; 12+ messages in thread From: Gilles Chanteperdrix @ 2010-12-07 12:09 UTC (permalink / raw) To: Anders Blomdell; +Cc: xenomai@xenomai.org Anders Blomdell wrote: > On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote: >> Anders Blomdell wrote: >>> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 >>> 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails with the >>> attached kernel OOPS, a notable difference between the 4.5.1 compiled >>> version and a working one built with gcc-4.4.4 on the same system with >>> the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not >>> inlined, is this anybody has seen before? >> No, that is new, we need to see the disassembly of __rthal_x86_nodiv_ullimd > > objdump -S: > > static inline __attribute__((const)) unsigned long long > __rthal_x86_nodiv_ullimd(const unsigned long long op, > const unsigned long long frac, > unsigned integ) > { > e7a8: 55 push %ebp > e7a9: 89 e5 mov %esp,%ebp > e7ab: 57 push %edi > e7ac: 56 push %esi > e7ad: 53 push %ebx > e7ae: 83 ec 10 sub $0x10,%esp > e7b1: 8d 7d 08 lea 0x8(%ebp),%edi > e7b4: e8 fc ff ff ff call e7b5 <__rthal_x86_nodiv_ullimd+0xd> > e7b9: 8b 1f mov (%edi),%ebx > e7bb: 8b 4f 04 mov 0x4(%edi),%ecx > register unsigned rm __asm__("esi"); > register unsigned rh __asm__("edi"); > unsigned fracl, frach, opl, oph; > register unsigned long long t; > > __rthal_u64tou32(op, oph, opl); > e7be: 89 45 e8 mov %eax,-0x18(%ebp) > __rthal_u64tou32(frac, frach, fracl); > e7c1: 89 5d f0 mov %ebx,-0x10(%ebp) > register unsigned rm __asm__("esi"); > register unsigned rh __asm__("edi"); > unsigned fracl, frach, opl, oph; > register unsigned long long t; > > __rthal_u64tou32(op, oph, opl); > e7c4: 89 55 e4 mov %edx,-0x1c(%ebp) > __rthal_u64tou32(frac, frach, fracl); > e7c7: 89 4d ec mov %ecx,-0x14(%ebp) > > __asm__ ("mov %[oph], %%eax\n\t" > e7ca: 8b 45 e4 mov -0x1c(%ebp),%eax > e7cd: f7 65 ec mull -0x14(%ebp) > e7d0: 89 c6 mov %eax,%esi > e7d2: 89 d7 mov %edx,%edi > e7d4: 8b 45 e8 mov -0x18(%ebp),%eax > e7d7: f7 65 f0 mull -0x10(%ebp) > e7da: 89 d1 mov %edx,%ecx > e7dc: d1 e0 shl %eax > e7de: 83 d1 00 adc $0x0,%ecx > e7e1: 83 d6 00 adc $0x0,%esi > e7e4: 83 d7 00 adc $0x0,%edi > e7e7: 8b 45 e4 mov -0x1c(%ebp),%eax > e7ea: f7 65 f0 mull -0x10(%ebp) > e7ed: 01 c1 add %eax,%ecx > e7ef: 11 d6 adc %edx,%esi > e7f1: 83 d7 00 adc $0x0,%edi > e7f4: 8b 45 e8 mov -0x18(%ebp),%eax > e7f7: f7 65 ec mull -0x14(%ebp) > e7fa: 01 c1 add %eax,%ecx > e7fc: 11 d6 adc %edx,%esi > e7fe: 83 d7 00 adc $0x0,%edi > e801: 8b 45 e8 mov -0x18(%ebp),%eax > e804: f7 67 08 mull 0x8(%edi) Problem is here: edi is used by gcc as if it contained an address whereas it is used by the assembly for the computation. Should be marked "early clobber". So, in include/asm-x86/arith_32.h, replace: : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=D"(rh), "=A"(t) with: : [rl]"=&c"(rl), [rm]"=&S"(rm), [rh]"=&D"(rh), "=&A"(t) > But us I said, in the working version, the code seems to be inlined > everywhere. Should I send the two object modules as well (probably as a > private message?). The code should work the same whatever gcc decides regarding inlining. Whether we like gcc decision is a different issue. Note that there is an option to get gcc to go back to the old behaviour (inlining as the source command). -- Gilles. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-07 12:09 ` Gilles Chanteperdrix @ 2010-12-07 14:14 ` Anders Blomdell 2010-12-07 16:20 ` Anders Blomdell 2010-12-07 20:21 ` Gilles Chanteperdrix 0 siblings, 2 replies; 12+ messages in thread From: Anders Blomdell @ 2010-12-07 14:14 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote: > Anders Blomdell wrote: >> On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote: >>> Anders Blomdell wrote: >>>> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 >>>> 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails with the >>>> attached kernel OOPS, a notable difference between the 4.5.1 compiled >>>> version and a working one built with gcc-4.4.4 on the same system with >>>> the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not >>>> inlined, is this anybody has seen before? >>> No, that is new, we need to see the disassembly of __rthal_x86_nodiv_ullimd >> >> objdump -S: >> >> static inline __attribute__((const)) unsigned long long >> __rthal_x86_nodiv_ullimd(const unsigned long long op, >> const unsigned long long frac, >> unsigned integ) >> { >> e7a8: 55 push %ebp >> e7a9: 89 e5 mov %esp,%ebp >> e7ab: 57 push %edi >> e7ac: 56 push %esi >> e7ad: 53 push %ebx >> e7ae: 83 ec 10 sub $0x10,%esp >> e7b1: 8d 7d 08 lea 0x8(%ebp),%edi >> e7b4: e8 fc ff ff ff call e7b5<__rthal_x86_nodiv_ullimd+0xd> >> e7b9: 8b 1f mov (%edi),%ebx >> e7bb: 8b 4f 04 mov 0x4(%edi),%ecx >> register unsigned rm __asm__("esi"); >> register unsigned rh __asm__("edi"); >> unsigned fracl, frach, opl, oph; >> register unsigned long long t; >> >> __rthal_u64tou32(op, oph, opl); >> e7be: 89 45 e8 mov %eax,-0x18(%ebp) >> __rthal_u64tou32(frac, frach, fracl); >> e7c1: 89 5d f0 mov %ebx,-0x10(%ebp) >> register unsigned rm __asm__("esi"); >> register unsigned rh __asm__("edi"); >> unsigned fracl, frach, opl, oph; >> register unsigned long long t; >> >> __rthal_u64tou32(op, oph, opl); >> e7c4: 89 55 e4 mov %edx,-0x1c(%ebp) >> __rthal_u64tou32(frac, frach, fracl); >> e7c7: 89 4d ec mov %ecx,-0x14(%ebp) >> >> __asm__ ("mov %[oph], %%eax\n\t" >> e7ca: 8b 45 e4 mov -0x1c(%ebp),%eax >> e7cd: f7 65 ec mull -0x14(%ebp) >> e7d0: 89 c6 mov %eax,%esi >> e7d2: 89 d7 mov %edx,%edi >> e7d4: 8b 45 e8 mov -0x18(%ebp),%eax >> e7d7: f7 65 f0 mull -0x10(%ebp) >> e7da: 89 d1 mov %edx,%ecx >> e7dc: d1 e0 shl %eax >> e7de: 83 d1 00 adc $0x0,%ecx >> e7e1: 83 d6 00 adc $0x0,%esi >> e7e4: 83 d7 00 adc $0x0,%edi >> e7e7: 8b 45 e4 mov -0x1c(%ebp),%eax >> e7ea: f7 65 f0 mull -0x10(%ebp) >> e7ed: 01 c1 add %eax,%ecx >> e7ef: 11 d6 adc %edx,%esi >> e7f1: 83 d7 00 adc $0x0,%edi >> e7f4: 8b 45 e8 mov -0x18(%ebp),%eax >> e7f7: f7 65 ec mull -0x14(%ebp) >> e7fa: 01 c1 add %eax,%ecx >> e7fc: 11 d6 adc %edx,%esi >> e7fe: 83 d7 00 adc $0x0,%edi >> e801: 8b 45 e8 mov -0x18(%ebp),%eax >> e804: f7 67 08 mull 0x8(%edi) > > Problem is here: edi is used by gcc as if it contained an address > whereas it is used by the assembly for the computation. Should be marked > "early clobber". So, > > in include/asm-x86/arith_32.h, replace: > > : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=D"(rh), "=A"(t) > > with: > > : [rl]"=&c"(rl), [rm]"=&S"(rm), [rh]"=&D"(rh), "=&A"(t) > > No cigar (:-() arch/x86/include/asm/xenomai/arith_32.h: In function ‘__rthal_x86_nodiv_ullimd’: arch/x86/include/asm/xenomai/arith_32.h:154:2: error: can't find a register in class ‘DIREG’ while reloading ‘asm’ arch/x86/include/asm/xenomai/arith_32.h:154:2: error: ‘asm’ operand has impossible constraints Forcing compilation with optimizations besides -Os seems to work. >> But us I said, in the working version, the code seems to be inlined >> everywhere. Should I send the two object modules as well (probably as a >> private message?). > > The code should work the same whatever gcc decides regarding inlining. > Whether we like gcc decision is a different issue. Agreed > Note that there is an > option to get gcc to go back to the old behaviour (inlining as the > source command). What option is that? /Anders -- Anders Blomdell Email: anders.blomdell@domain.hid Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-07 14:14 ` Anders Blomdell @ 2010-12-07 16:20 ` Anders Blomdell 2010-12-07 20:21 ` Gilles Chanteperdrix 1 sibling, 0 replies; 12+ messages in thread From: Anders Blomdell @ 2010-12-07 16:20 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org [-- Attachment #1: Type: text/plain, Size: 4578 bytes --] On 12/07/2010 03:14 PM, Anders Blomdell wrote: > > On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote: > > Anders Blomdell wrote: > >> On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote: > >>> Anders Blomdell wrote: > >>>> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 > >>>> 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails > with the > >>>> attached kernel OOPS, a notable difference between the 4.5.1 compiled > >>>> version and a working one built with gcc-4.4.4 on the same system > with > >>>> the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not > >>>> inlined, is this anybody has seen before? > >>> No, that is new, we need to see the disassembly of > __rthal_x86_nodiv_ullimd > >> > >> objdump -S: > >> > >> static inline __attribute__((const)) unsigned long long > >> __rthal_x86_nodiv_ullimd(const unsigned long long op, > >> const unsigned long long frac, > >> unsigned integ) > >> { > >> e7a8: 55 push %ebp > >> e7a9: 89 e5 mov %esp,%ebp > >> e7ab: 57 push %edi > >> e7ac: 56 push %esi > >> e7ad: 53 push %ebx > >> e7ae: 83 ec 10 sub $0x10,%esp > >> e7b1: 8d 7d 08 lea 0x8(%ebp),%edi > >> e7b4: e8 fc ff ff ff call e7b5<__rthal_x86_nodiv_ullimd+0xd> > >> e7b9: 8b 1f mov (%edi),%ebx > >> e7bb: 8b 4f 04 mov 0x4(%edi),%ecx > >> register unsigned rm __asm__("esi"); > >> register unsigned rh __asm__("edi"); > >> unsigned fracl, frach, opl, oph; > >> register unsigned long long t; > >> > >> __rthal_u64tou32(op, oph, opl); > >> e7be: 89 45 e8 mov %eax,-0x18(%ebp) > >> __rthal_u64tou32(frac, frach, fracl); > >> e7c1: 89 5d f0 mov %ebx,-0x10(%ebp) > >> register unsigned rm __asm__("esi"); > >> register unsigned rh __asm__("edi"); > >> unsigned fracl, frach, opl, oph; > >> register unsigned long long t; > >> > >> __rthal_u64tou32(op, oph, opl); > >> e7c4: 89 55 e4 mov %edx,-0x1c(%ebp) > >> __rthal_u64tou32(frac, frach, fracl); > >> e7c7: 89 4d ec mov %ecx,-0x14(%ebp) > >> > >> __asm__ ("mov %[oph], %%eax\n\t" > >> e7ca: 8b 45 e4 mov -0x1c(%ebp),%eax > >> e7cd: f7 65 ec mull -0x14(%ebp) > >> e7d0: 89 c6 mov %eax,%esi > >> e7d2: 89 d7 mov %edx,%edi > >> e7d4: 8b 45 e8 mov -0x18(%ebp),%eax > >> e7d7: f7 65 f0 mull -0x10(%ebp) > >> e7da: 89 d1 mov %edx,%ecx > >> e7dc: d1 e0 shl %eax > >> e7de: 83 d1 00 adc $0x0,%ecx > >> e7e1: 83 d6 00 adc $0x0,%esi > >> e7e4: 83 d7 00 adc $0x0,%edi > >> e7e7: 8b 45 e4 mov -0x1c(%ebp),%eax > >> e7ea: f7 65 f0 mull -0x10(%ebp) > >> e7ed: 01 c1 add %eax,%ecx > >> e7ef: 11 d6 adc %edx,%esi > >> e7f1: 83 d7 00 adc $0x0,%edi > >> e7f4: 8b 45 e8 mov -0x18(%ebp),%eax > >> e7f7: f7 65 ec mull -0x14(%ebp) > >> e7fa: 01 c1 add %eax,%ecx > >> e7fc: 11 d6 adc %edx,%esi > >> e7fe: 83 d7 00 adc $0x0,%edi > >> e801: 8b 45 e8 mov -0x18(%ebp),%eax > >> e804: f7 67 08 mull 0x8(%edi) > > > > Problem is here: edi is used by gcc as if it contained an address > > whereas it is used by the assembly for the computation. Should be marked > > "early clobber". So, > > > > in include/asm-x86/arith_32.h, replace: > > > > : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=D"(rh), "=A"(t) > > > > with: > > > > : [rl]"=&c"(rl), [rm]"=&S"(rm), [rh]"=&D"(rh), "=&A"(t) > > > > > > No cigar (:-() > > arch/x86/include/asm/xenomai/arith_32.h: In function > ‘__rthal_x86_nodiv_ullimd’: > arch/x86/include/asm/xenomai/arith_32.h:154:2: error: can't find a > register in class ‘DIREG’ while reloading ‘asm’ > arch/x86/include/asm/xenomai/arith_32.h:154:2: error: ‘asm’ operand has > impossible constraints > > Forcing compilation with optimizations besides -Os seems to work. Patch that makes code compile and generates modules that loads is attached. > > >> But us I said, in the working version, the code seems to be inlined > >> everywhere. Should I send the two object modules as well (probably as a > >> private message?). > > > > The code should work the same whatever gcc decides regarding inlining. > > Whether we like gcc decision is a different issue. > Agreed > > > Note that there is an > > option to get gcc to go back to the old behaviour (inlining as the > > source command). > What option is that? > > /Anders > -- Anders Blomdell Email: anders.blomdell@domain.hid Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden [-- Attachment #2: gcc_4.5.1.patch --] [-- Type: text/x-patch, Size: 819 bytes --] --- a/include/asm-x86/arith_32.h 2010-05-18 20:31:15.000000000 +0200 +++ b/include/asm-x86/arith_32.h 2010-12-07 13:22:32.000000000 +0100 @@ -179,8 +179,8 @@ "mov %[oph], %%edx\n\t" "imul %[integ], %%edx\n\t" "add %[rh], %%edx\n\t" - : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=D"(rh), "=A"(t) + : [rl]"=&c"(rl), [rm]"=&S"(rm), [rh]"=&D"(rh), "=&A"(t) : [opl]"m"(opl), [oph]"m"(oph), [fracl]"m"(fracl), [frach]"m"(frach), [integ]"m"(integ) : "cc"); --- a/ksrc/nucleus/Makefile 2010-05-18 20:31:16.000000000 +0200 +++ b/ksrc/nucleus/Makefile 2010-12-07 16:09:46.000000000 +0100 @@ -21,7 +21,7 @@ # exist on initcalls defined by other object files. xeno_nucleus-y += module.o -EXTRA_CFLAGS += -D__IN_XENOMAI__ -Iinclude/xenomai +EXTRA_CFLAGS += -D__IN_XENOMAI__ -Iinclude/xenomai -O3 else ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-07 14:14 ` Anders Blomdell 2010-12-07 16:20 ` Anders Blomdell @ 2010-12-07 20:21 ` Gilles Chanteperdrix 2010-12-08 7:33 ` Anders Blomdell 1 sibling, 1 reply; 12+ messages in thread From: Gilles Chanteperdrix @ 2010-12-07 20:21 UTC (permalink / raw) To: Anders Blomdell; +Cc: xenomai@xenomai.org Anders Blomdell wrote: > On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote: > > Anders Blomdell wrote: > >> On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote: > >>> Anders Blomdell wrote: > >>>> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 > >>>> 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails > with the > >>>> attached kernel OOPS, a notable difference between the 4.5.1 compiled > >>>> version and a working one built with gcc-4.4.4 on the same system with > >>>> the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not > >>>> inlined, is this anybody has seen before? > >>> No, that is new, we need to see the disassembly of > __rthal_x86_nodiv_ullimd > >> > >> objdump -S: > >> > >> static inline __attribute__((const)) unsigned long long > >> __rthal_x86_nodiv_ullimd(const unsigned long long op, > >> const unsigned long long frac, > >> unsigned integ) > >> { > >> e7a8: 55 push %ebp > >> e7a9: 89 e5 mov %esp,%ebp > >> e7ab: 57 push %edi > >> e7ac: 56 push %esi > >> e7ad: 53 push %ebx > >> e7ae: 83 ec 10 sub $0x10,%esp > >> e7b1: 8d 7d 08 lea 0x8(%ebp),%edi > >> e7b4: e8 fc ff ff ff call > e7b5<__rthal_x86_nodiv_ullimd+0xd> > >> e7b9: 8b 1f mov (%edi),%ebx > >> e7bb: 8b 4f 04 mov 0x4(%edi),%ecx > >> register unsigned rm __asm__("esi"); > >> register unsigned rh __asm__("edi"); > >> unsigned fracl, frach, opl, oph; > >> register unsigned long long t; > >> > >> __rthal_u64tou32(op, oph, opl); > >> e7be: 89 45 e8 mov %eax,-0x18(%ebp) > >> __rthal_u64tou32(frac, frach, fracl); > >> e7c1: 89 5d f0 mov %ebx,-0x10(%ebp) > >> register unsigned rm __asm__("esi"); > >> register unsigned rh __asm__("edi"); > >> unsigned fracl, frach, opl, oph; > >> register unsigned long long t; > >> > >> __rthal_u64tou32(op, oph, opl); > >> e7c4: 89 55 e4 mov %edx,-0x1c(%ebp) > >> __rthal_u64tou32(frac, frach, fracl); > >> e7c7: 89 4d ec mov %ecx,-0x14(%ebp) > >> > >> __asm__ ("mov %[oph], %%eax\n\t" > >> e7ca: 8b 45 e4 mov -0x1c(%ebp),%eax > >> e7cd: f7 65 ec mull -0x14(%ebp) > >> e7d0: 89 c6 mov %eax,%esi > >> e7d2: 89 d7 mov %edx,%edi > >> e7d4: 8b 45 e8 mov -0x18(%ebp),%eax > >> e7d7: f7 65 f0 mull -0x10(%ebp) > >> e7da: 89 d1 mov %edx,%ecx > >> e7dc: d1 e0 shl %eax > >> e7de: 83 d1 00 adc $0x0,%ecx > >> e7e1: 83 d6 00 adc $0x0,%esi > >> e7e4: 83 d7 00 adc $0x0,%edi > >> e7e7: 8b 45 e4 mov -0x1c(%ebp),%eax > >> e7ea: f7 65 f0 mull -0x10(%ebp) > >> e7ed: 01 c1 add %eax,%ecx > >> e7ef: 11 d6 adc %edx,%esi > >> e7f1: 83 d7 00 adc $0x0,%edi > >> e7f4: 8b 45 e8 mov -0x18(%ebp),%eax > >> e7f7: f7 65 ec mull -0x14(%ebp) > >> e7fa: 01 c1 add %eax,%ecx > >> e7fc: 11 d6 adc %edx,%esi > >> e7fe: 83 d7 00 adc $0x0,%edi > >> e801: 8b 45 e8 mov -0x18(%ebp),%eax > >> e804: f7 67 08 mull 0x8(%edi) > > > > Problem is here: edi is used by gcc as if it contained an address > > whereas it is used by the assembly for the computation. Should be marked > > "early clobber". So, > > > > in include/asm-x86/arith_32.h, replace: > > > > : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=D"(rh), "=A"(t) > > > > with: > > > > : [rl]"=&c"(rl), [rm]"=&S"(rm), [rh]"=&D"(rh), "=&A"(t) > > > > > > No cigar (:-() Ok. Maybe we can try something less radical, such as: : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=&D"(rh), "=A"(t) This is incorrect, but we can hope for the best... -- Gilles. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-07 20:21 ` Gilles Chanteperdrix @ 2010-12-08 7:33 ` Anders Blomdell 2010-12-08 8:50 ` Gilles Chanteperdrix 0 siblings, 1 reply; 12+ messages in thread From: Anders Blomdell @ 2010-12-08 7:33 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org On 2010-12-07 21.21, Gilles Chanteperdrix wrote: > Anders Blomdell wrote: >> On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote: >> > Anders Blomdell wrote: >> >> On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote: >> >>> Anders Blomdell wrote: >> >>>> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 >> >>>> 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails >> with the >> >>>> attached kernel OOPS, a notable difference between the 4.5.1 compiled >> >>>> version and a working one built with gcc-4.4.4 on the same system with >> >>>> the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not >> >>>> inlined, is this anybody has seen before? >> >>> No, that is new, we need to see the disassembly of >> __rthal_x86_nodiv_ullimd >> >> >> >> objdump -S: >> >> >> >> static inline __attribute__((const)) unsigned long long >> >> __rthal_x86_nodiv_ullimd(const unsigned long long op, >> >> const unsigned long long frac, >> >> unsigned integ) >> >> { >> >> e7a8: 55 push %ebp >> >> e7a9: 89 e5 mov %esp,%ebp >> >> e7ab: 57 push %edi >> >> e7ac: 56 push %esi >> >> e7ad: 53 push %ebx >> >> e7ae: 83 ec 10 sub $0x10,%esp >> >> e7b1: 8d 7d 08 lea 0x8(%ebp),%edi >> >> e7b4: e8 fc ff ff ff call >> e7b5<__rthal_x86_nodiv_ullimd+0xd> >> >> e7b9: 8b 1f mov (%edi),%ebx >> >> e7bb: 8b 4f 04 mov 0x4(%edi),%ecx >> >> register unsigned rm __asm__("esi"); >> >> register unsigned rh __asm__("edi"); >> >> unsigned fracl, frach, opl, oph; >> >> register unsigned long long t; >> >> >> >> __rthal_u64tou32(op, oph, opl); >> >> e7be: 89 45 e8 mov %eax,-0x18(%ebp) >> >> __rthal_u64tou32(frac, frach, fracl); >> >> e7c1: 89 5d f0 mov %ebx,-0x10(%ebp) >> >> register unsigned rm __asm__("esi"); >> >> register unsigned rh __asm__("edi"); >> >> unsigned fracl, frach, opl, oph; >> >> register unsigned long long t; >> >> >> >> __rthal_u64tou32(op, oph, opl); >> >> e7c4: 89 55 e4 mov %edx,-0x1c(%ebp) >> >> __rthal_u64tou32(frac, frach, fracl); >> >> e7c7: 89 4d ec mov %ecx,-0x14(%ebp) >> >> >> >> __asm__ ("mov %[oph], %%eax\n\t" >> >> e7ca: 8b 45 e4 mov -0x1c(%ebp),%eax >> >> e7cd: f7 65 ec mull -0x14(%ebp) >> >> e7d0: 89 c6 mov %eax,%esi >> >> e7d2: 89 d7 mov %edx,%edi >> >> e7d4: 8b 45 e8 mov -0x18(%ebp),%eax >> >> e7d7: f7 65 f0 mull -0x10(%ebp) >> >> e7da: 89 d1 mov %edx,%ecx >> >> e7dc: d1 e0 shl %eax >> >> e7de: 83 d1 00 adc $0x0,%ecx >> >> e7e1: 83 d6 00 adc $0x0,%esi >> >> e7e4: 83 d7 00 adc $0x0,%edi >> >> e7e7: 8b 45 e4 mov -0x1c(%ebp),%eax >> >> e7ea: f7 65 f0 mull -0x10(%ebp) >> >> e7ed: 01 c1 add %eax,%ecx >> >> e7ef: 11 d6 adc %edx,%esi >> >> e7f1: 83 d7 00 adc $0x0,%edi >> >> e7f4: 8b 45 e8 mov -0x18(%ebp),%eax >> >> e7f7: f7 65 ec mull -0x14(%ebp) >> >> e7fa: 01 c1 add %eax,%ecx >> >> e7fc: 11 d6 adc %edx,%esi >> >> e7fe: 83 d7 00 adc $0x0,%edi >> >> e801: 8b 45 e8 mov -0x18(%ebp),%eax >> >> e804: f7 67 08 mull 0x8(%edi) >> > >> > Problem is here: edi is used by gcc as if it contained an address >> > whereas it is used by the assembly for the computation. Should be marked >> > "early clobber". So, >> > >> > in include/asm-x86/arith_32.h, replace: >> > >> > : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=D"(rh), "=A"(t) >> > >> > with: >> > >> > : [rl]"=&c"(rl), [rm]"=&S"(rm), [rh]"=&D"(rh), "=&A"(t) >> > >> > >> >> No cigar (:-() > > Ok. Maybe we can try something less radical, such as: > > : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=&D"(rh), "=A"(t) > > This is incorrect, but we can hope for the best... As previously said, changing the optimization from -Os to anything else for xeno_nucleus (see patch in mail dated 'Tue, 07 Dec 2010 17:20:37 +0100'), solved that issue (incorrect code + hope for the best -> spurious disasters). Rather compile time errors than runtime errors. /Anders -- Anders Blomdell Email: anders.blomdell@domain.hid Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-08 7:33 ` Anders Blomdell @ 2010-12-08 8:50 ` Gilles Chanteperdrix 2010-12-08 9:15 ` Anders Blomdell 0 siblings, 1 reply; 12+ messages in thread From: Gilles Chanteperdrix @ 2010-12-08 8:50 UTC (permalink / raw) To: Anders Blomdell; +Cc: xenomai@xenomai.org Anders Blomdell wrote: > On 2010-12-07 21.21, Gilles Chanteperdrix wrote: >> Anders Blomdell wrote: >>> On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote: >>> > Anders Blomdell wrote: >>> >> On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote: >>> >>> Anders Blomdell wrote: >>> >>>> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 >>> >>>> 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails >>> with the >>> >>>> attached kernel OOPS, a notable difference between the 4.5.1 compiled >>> >>>> version and a working one built with gcc-4.4.4 on the same system with >>> >>>> the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not >>> >>>> inlined, is this anybody has seen before? >>> >>> No, that is new, we need to see the disassembly of >>> __rthal_x86_nodiv_ullimd >>> >> >>> >> objdump -S: >>> >> >>> >> static inline __attribute__((const)) unsigned long long >>> >> __rthal_x86_nodiv_ullimd(const unsigned long long op, >>> >> const unsigned long long frac, >>> >> unsigned integ) >>> >> { >>> >> e7a8: 55 push %ebp >>> >> e7a9: 89 e5 mov %esp,%ebp >>> >> e7ab: 57 push %edi >>> >> e7ac: 56 push %esi >>> >> e7ad: 53 push %ebx >>> >> e7ae: 83 ec 10 sub $0x10,%esp >>> >> e7b1: 8d 7d 08 lea 0x8(%ebp),%edi >>> >> e7b4: e8 fc ff ff ff call >>> e7b5<__rthal_x86_nodiv_ullimd+0xd> >>> >> e7b9: 8b 1f mov (%edi),%ebx >>> >> e7bb: 8b 4f 04 mov 0x4(%edi),%ecx >>> >> register unsigned rm __asm__("esi"); >>> >> register unsigned rh __asm__("edi"); >>> >> unsigned fracl, frach, opl, oph; >>> >> register unsigned long long t; >>> >> >>> >> __rthal_u64tou32(op, oph, opl); >>> >> e7be: 89 45 e8 mov %eax,-0x18(%ebp) >>> >> __rthal_u64tou32(frac, frach, fracl); >>> >> e7c1: 89 5d f0 mov %ebx,-0x10(%ebp) >>> >> register unsigned rm __asm__("esi"); >>> >> register unsigned rh __asm__("edi"); >>> >> unsigned fracl, frach, opl, oph; >>> >> register unsigned long long t; >>> >> >>> >> __rthal_u64tou32(op, oph, opl); >>> >> e7c4: 89 55 e4 mov %edx,-0x1c(%ebp) >>> >> __rthal_u64tou32(frac, frach, fracl); >>> >> e7c7: 89 4d ec mov %ecx,-0x14(%ebp) >>> >> >>> >> __asm__ ("mov %[oph], %%eax\n\t" >>> >> e7ca: 8b 45 e4 mov -0x1c(%ebp),%eax >>> >> e7cd: f7 65 ec mull -0x14(%ebp) >>> >> e7d0: 89 c6 mov %eax,%esi >>> >> e7d2: 89 d7 mov %edx,%edi >>> >> e7d4: 8b 45 e8 mov -0x18(%ebp),%eax >>> >> e7d7: f7 65 f0 mull -0x10(%ebp) >>> >> e7da: 89 d1 mov %edx,%ecx >>> >> e7dc: d1 e0 shl %eax >>> >> e7de: 83 d1 00 adc $0x0,%ecx >>> >> e7e1: 83 d6 00 adc $0x0,%esi >>> >> e7e4: 83 d7 00 adc $0x0,%edi >>> >> e7e7: 8b 45 e4 mov -0x1c(%ebp),%eax >>> >> e7ea: f7 65 f0 mull -0x10(%ebp) >>> >> e7ed: 01 c1 add %eax,%ecx >>> >> e7ef: 11 d6 adc %edx,%esi >>> >> e7f1: 83 d7 00 adc $0x0,%edi >>> >> e7f4: 8b 45 e8 mov -0x18(%ebp),%eax >>> >> e7f7: f7 65 ec mull -0x14(%ebp) >>> >> e7fa: 01 c1 add %eax,%ecx >>> >> e7fc: 11 d6 adc %edx,%esi >>> >> e7fe: 83 d7 00 adc $0x0,%edi >>> >> e801: 8b 45 e8 mov -0x18(%ebp),%eax >>> >> e804: f7 67 08 mull 0x8(%edi) >>> > >>> > Problem is here: edi is used by gcc as if it contained an address >>> > whereas it is used by the assembly for the computation. Should be marked >>> > "early clobber". So, >>> > >>> > in include/asm-x86/arith_32.h, replace: >>> > >>> > : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=D"(rh), "=A"(t) >>> > >>> > with: >>> > >>> > : [rl]"=&c"(rl), [rm]"=&S"(rm), [rh]"=&D"(rh), "=&A"(t) >>> > >>> > >>> >>> No cigar (:-() >> Ok. Maybe we can try something less radical, such as: >> >> : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=&D"(rh), "=A"(t) >> >> This is incorrect, but we can hope for the best... > As previously said, changing the optimization from -Os to anything else for > xeno_nucleus (see patch in mail dated 'Tue, 07 Dec 2010 17:20:37 +0100'), solved > that issue (incorrect code + hope for the best -> spurious disasters). Rather > compile time errors than runtime errors. We are not going to decide instead of the user what optimization level to use, if he wants to use -Os, we have to make it work for -Os. If this one does not work, we have other things to try. -- Gilles. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-08 8:50 ` Gilles Chanteperdrix @ 2010-12-08 9:15 ` Anders Blomdell 2010-12-08 9:34 ` Gilles Chanteperdrix 0 siblings, 1 reply; 12+ messages in thread From: Anders Blomdell @ 2010-12-08 9:15 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org On 2010-12-08 09.50, Gilles Chanteperdrix wrote: > Anders Blomdell wrote: >> On 2010-12-07 21.21, Gilles Chanteperdrix wrote: >>> Anders Blomdell wrote: >>>> On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote: >>>> > Anders Blomdell wrote: >>>> >> On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote: >>>> >>> Anders Blomdell wrote: >>>> >>>> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 >>>> >>>> 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails >>>> with the >>>> >>>> attached kernel OOPS, a notable difference between the 4.5.1 compiled >>>> >>>> version and a working one built with gcc-4.4.4 on the same system with >>>> >>>> the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not >>>> >>>> inlined, is this anybody has seen before? >>>> >>> No, that is new, we need to see the disassembly of >>>> __rthal_x86_nodiv_ullimd >>>> >> >>>> >> objdump -S: >>>> >> >>>> >> static inline __attribute__((const)) unsigned long long >>>> >> __rthal_x86_nodiv_ullimd(const unsigned long long op, >>>> >> const unsigned long long frac, >>>> >> unsigned integ) >>>> >> { >>>> >> e7a8: 55 push %ebp >>>> >> e7a9: 89 e5 mov %esp,%ebp >>>> >> e7ab: 57 push %edi >>>> >> e7ac: 56 push %esi >>>> >> e7ad: 53 push %ebx >>>> >> e7ae: 83 ec 10 sub $0x10,%esp >>>> >> e7b1: 8d 7d 08 lea 0x8(%ebp),%edi >>>> >> e7b4: e8 fc ff ff ff call >>>> e7b5<__rthal_x86_nodiv_ullimd+0xd> >>>> >> e7b9: 8b 1f mov (%edi),%ebx >>>> >> e7bb: 8b 4f 04 mov 0x4(%edi),%ecx >>>> >> register unsigned rm __asm__("esi"); >>>> >> register unsigned rh __asm__("edi"); >>>> >> unsigned fracl, frach, opl, oph; >>>> >> register unsigned long long t; >>>> >> >>>> >> __rthal_u64tou32(op, oph, opl); >>>> >> e7be: 89 45 e8 mov %eax,-0x18(%ebp) >>>> >> __rthal_u64tou32(frac, frach, fracl); >>>> >> e7c1: 89 5d f0 mov %ebx,-0x10(%ebp) >>>> >> register unsigned rm __asm__("esi"); >>>> >> register unsigned rh __asm__("edi"); >>>> >> unsigned fracl, frach, opl, oph; >>>> >> register unsigned long long t; >>>> >> >>>> >> __rthal_u64tou32(op, oph, opl); >>>> >> e7c4: 89 55 e4 mov %edx,-0x1c(%ebp) >>>> >> __rthal_u64tou32(frac, frach, fracl); >>>> >> e7c7: 89 4d ec mov %ecx,-0x14(%ebp) >>>> >> >>>> >> __asm__ ("mov %[oph], %%eax\n\t" >>>> >> e7ca: 8b 45 e4 mov -0x1c(%ebp),%eax >>>> >> e7cd: f7 65 ec mull -0x14(%ebp) >>>> >> e7d0: 89 c6 mov %eax,%esi >>>> >> e7d2: 89 d7 mov %edx,%edi >>>> >> e7d4: 8b 45 e8 mov -0x18(%ebp),%eax >>>> >> e7d7: f7 65 f0 mull -0x10(%ebp) >>>> >> e7da: 89 d1 mov %edx,%ecx >>>> >> e7dc: d1 e0 shl %eax >>>> >> e7de: 83 d1 00 adc $0x0,%ecx >>>> >> e7e1: 83 d6 00 adc $0x0,%esi >>>> >> e7e4: 83 d7 00 adc $0x0,%edi >>>> >> e7e7: 8b 45 e4 mov -0x1c(%ebp),%eax >>>> >> e7ea: f7 65 f0 mull -0x10(%ebp) >>>> >> e7ed: 01 c1 add %eax,%ecx >>>> >> e7ef: 11 d6 adc %edx,%esi >>>> >> e7f1: 83 d7 00 adc $0x0,%edi >>>> >> e7f4: 8b 45 e8 mov -0x18(%ebp),%eax >>>> >> e7f7: f7 65 ec mull -0x14(%ebp) >>>> >> e7fa: 01 c1 add %eax,%ecx >>>> >> e7fc: 11 d6 adc %edx,%esi >>>> >> e7fe: 83 d7 00 adc $0x0,%edi >>>> >> e801: 8b 45 e8 mov -0x18(%ebp),%eax >>>> >> e804: f7 67 08 mull 0x8(%edi) >>>> > >>>> > Problem is here: edi is used by gcc as if it contained an address >>>> > whereas it is used by the assembly for the computation. Should be marked >>>> > "early clobber". So, >>>> > >>>> > in include/asm-x86/arith_32.h, replace: >>>> > >>>> > : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=D"(rh), "=A"(t) >>>> > >>>> > with: >>>> > >>>> > : [rl]"=&c"(rl), [rm]"=&S"(rm), [rh]"=&D"(rh), "=&A"(t) >>>> > >>>> > >>>> >>>> No cigar (:-() >>> Ok. Maybe we can try something less radical, such as: >>> >>> : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=&D"(rh), "=A"(t) >>> >>> This is incorrect, but we can hope for the best... >> As previously said, changing the optimization from -Os to anything else for >> xeno_nucleus (see patch in mail dated 'Tue, 07 Dec 2010 17:20:37 +0100'), solved >> that issue (incorrect code + hope for the best -> spurious disasters). Rather >> compile time errors than runtime errors. > > We are not going to decide instead of the user what optimization level > to use, if he wants to use -Os, we have to make it work for -Os. If this > one does not work, we have other things to try. Then start with something that you belive is correct, I *WILL NOT* test something which you think is incorrect. /Anders -- Anders Blomdell Email: anders.blomdell@domain.hid Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai-core] Problem with gcc-4.5.1 2010-12-08 9:15 ` Anders Blomdell @ 2010-12-08 9:34 ` Gilles Chanteperdrix 0 siblings, 0 replies; 12+ messages in thread From: Gilles Chanteperdrix @ 2010-12-08 9:34 UTC (permalink / raw) To: Anders Blomdell; +Cc: xenomai@xenomai.org Anders Blomdell wrote: > On 2010-12-08 09.50, Gilles Chanteperdrix wrote: >> Anders Blomdell wrote: >>> On 2010-12-07 21.21, Gilles Chanteperdrix wrote: >>>> Anders Blomdell wrote: >>>>> On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote: >>>>> > Anders Blomdell wrote: >>>>> >> On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote: >>>>> >>> Anders Blomdell wrote: >>>>> >>>> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1 >>>>> >>>> 20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails >>>>> with the >>>>> >>>> attached kernel OOPS, a notable difference between the 4.5.1 compiled >>>>> >>>> version and a working one built with gcc-4.4.4 on the same system with >>>>> >>>> the same configuration, sis tthat __rthal_x86_nodiv_ullimd is not >>>>> >>>> inlined, is this anybody has seen before? >>>>> >>> No, that is new, we need to see the disassembly of >>>>> __rthal_x86_nodiv_ullimd >>>>> >> >>>>> >> objdump -S: >>>>> >> >>>>> >> static inline __attribute__((const)) unsigned long long >>>>> >> __rthal_x86_nodiv_ullimd(const unsigned long long op, >>>>> >> const unsigned long long frac, >>>>> >> unsigned integ) >>>>> >> { >>>>> >> e7a8: 55 push %ebp >>>>> >> e7a9: 89 e5 mov %esp,%ebp >>>>> >> e7ab: 57 push %edi >>>>> >> e7ac: 56 push %esi >>>>> >> e7ad: 53 push %ebx >>>>> >> e7ae: 83 ec 10 sub $0x10,%esp >>>>> >> e7b1: 8d 7d 08 lea 0x8(%ebp),%edi >>>>> >> e7b4: e8 fc ff ff ff call >>>>> e7b5<__rthal_x86_nodiv_ullimd+0xd> >>>>> >> e7b9: 8b 1f mov (%edi),%ebx >>>>> >> e7bb: 8b 4f 04 mov 0x4(%edi),%ecx >>>>> >> register unsigned rm __asm__("esi"); >>>>> >> register unsigned rh __asm__("edi"); >>>>> >> unsigned fracl, frach, opl, oph; >>>>> >> register unsigned long long t; >>>>> >> >>>>> >> __rthal_u64tou32(op, oph, opl); >>>>> >> e7be: 89 45 e8 mov %eax,-0x18(%ebp) >>>>> >> __rthal_u64tou32(frac, frach, fracl); >>>>> >> e7c1: 89 5d f0 mov %ebx,-0x10(%ebp) >>>>> >> register unsigned rm __asm__("esi"); >>>>> >> register unsigned rh __asm__("edi"); >>>>> >> unsigned fracl, frach, opl, oph; >>>>> >> register unsigned long long t; >>>>> >> >>>>> >> __rthal_u64tou32(op, oph, opl); >>>>> >> e7c4: 89 55 e4 mov %edx,-0x1c(%ebp) >>>>> >> __rthal_u64tou32(frac, frach, fracl); >>>>> >> e7c7: 89 4d ec mov %ecx,-0x14(%ebp) >>>>> >> >>>>> >> __asm__ ("mov %[oph], %%eax\n\t" >>>>> >> e7ca: 8b 45 e4 mov -0x1c(%ebp),%eax >>>>> >> e7cd: f7 65 ec mull -0x14(%ebp) >>>>> >> e7d0: 89 c6 mov %eax,%esi >>>>> >> e7d2: 89 d7 mov %edx,%edi >>>>> >> e7d4: 8b 45 e8 mov -0x18(%ebp),%eax >>>>> >> e7d7: f7 65 f0 mull -0x10(%ebp) >>>>> >> e7da: 89 d1 mov %edx,%ecx >>>>> >> e7dc: d1 e0 shl %eax >>>>> >> e7de: 83 d1 00 adc $0x0,%ecx >>>>> >> e7e1: 83 d6 00 adc $0x0,%esi >>>>> >> e7e4: 83 d7 00 adc $0x0,%edi >>>>> >> e7e7: 8b 45 e4 mov -0x1c(%ebp),%eax >>>>> >> e7ea: f7 65 f0 mull -0x10(%ebp) >>>>> >> e7ed: 01 c1 add %eax,%ecx >>>>> >> e7ef: 11 d6 adc %edx,%esi >>>>> >> e7f1: 83 d7 00 adc $0x0,%edi >>>>> >> e7f4: 8b 45 e8 mov -0x18(%ebp),%eax >>>>> >> e7f7: f7 65 ec mull -0x14(%ebp) >>>>> >> e7fa: 01 c1 add %eax,%ecx >>>>> >> e7fc: 11 d6 adc %edx,%esi >>>>> >> e7fe: 83 d7 00 adc $0x0,%edi >>>>> >> e801: 8b 45 e8 mov -0x18(%ebp),%eax >>>>> >> e804: f7 67 08 mull 0x8(%edi) >>>>> > >>>>> > Problem is here: edi is used by gcc as if it contained an address >>>>> > whereas it is used by the assembly for the computation. Should be marked >>>>> > "early clobber". So, >>>>> > >>>>> > in include/asm-x86/arith_32.h, replace: >>>>> > >>>>> > : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=D"(rh), "=A"(t) >>>>> > >>>>> > with: >>>>> > >>>>> > : [rl]"=&c"(rl), [rm]"=&S"(rm), [rh]"=&D"(rh), "=&A"(t) >>>>> > >>>>> > >>>>> >>>>> No cigar (:-() >>>> Ok. Maybe we can try something less radical, such as: >>>> >>>> : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=&D"(rh), "=A"(t) >>>> >>>> This is incorrect, but we can hope for the best... >>> As previously said, changing the optimization from -Os to anything else for >>> xeno_nucleus (see patch in mail dated 'Tue, 07 Dec 2010 17:20:37 +0100'), solved >>> that issue (incorrect code + hope for the best -> spurious disasters). Rather >>> compile time errors than runtime errors. >> We are not going to decide instead of the user what optimization level >> to use, if he wants to use -Os, we have to make it work for -Os. If this >> one does not work, we have other things to try. > Then start with something that you belive is correct, I *WILL NOT* test > something which you think is incorrect. Well, the way I see it, it has been incorrect for at least two years, and when it generates wrong code, it will generate code which reliably oops, no spurious disaster, a completely plain bug. Anyway, here is correct code, which forces "integ" on the current function stack frame, so hopefully, will get gcc to address it relatively to ebp. It is pretty ugly, and will generate slightly worse code, for previous versions of gcc, even though the "incorrect" version worked, but we are working a compiler bug, so do not have much choice. If that does not work, we can still try and force inlining, or use the plain C version. diff --git a/include/asm-x86/arith_32.h b/include/asm-x86/arith_32.h index 517d391..11c9564 100644 --- a/include/asm-x86/arith_32.h +++ b/include/asm-x86/arith_32.h @@ -140,12 +140,13 @@ __rthal_i386_ulldiv (const unsigned long long ull, static inline __attribute__((const)) unsigned long long __rthal_x86_nodiv_ullimd(const unsigned long long op, const unsigned long long frac, - unsigned integ) + unsigned rhs_integ) { register unsigned rl __asm__("ecx"); register unsigned rm __asm__("esi"); register unsigned rh __asm__("edi"); unsigned fracl, frach, opl, oph; + volatile unsigned integ = rhs_integ; register unsigned long long t; __rthal_u64tou32(op, oph, opl); @@ -179,7 +180,7 @@ __rthal_x86_nodiv_ullimd(const unsigned long long op, "mov %[oph], %%edx\n\t" "imul %[integ], %%edx\n\t" "add %[rh], %%edx\n\t" - : [rl]"=c"(rl), [rm]"=S"(rm), [rh]"=D"(rh), "=A"(t) + : [rl]"=&c"(rl), [rm]"=&S"(rm), [rh]"=&D"(rh), "=&A"(t) : [opl]"m"(opl), [oph]"m"(oph), [fracl]"m"(fracl), [frach]"m"(frach), [integ]"m"(integ) : "cc"); -- Gilles. ^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-12-08 9:34 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-07 11:44 [Xenomai-core] Problem with gcc-4.5.1 Anders Blomdell 2010-12-07 11:51 ` Gilles Chanteperdrix 2010-12-07 11:57 ` Gilles Chanteperdrix 2010-12-07 11:58 ` Anders Blomdell 2010-12-07 12:09 ` Gilles Chanteperdrix 2010-12-07 14:14 ` Anders Blomdell 2010-12-07 16:20 ` Anders Blomdell 2010-12-07 20:21 ` Gilles Chanteperdrix 2010-12-08 7:33 ` Anders Blomdell 2010-12-08 8:50 ` Gilles Chanteperdrix 2010-12-08 9:15 ` Anders Blomdell 2010-12-08 9:34 ` Gilles Chanteperdrix
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.