* [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.