Re: GCC 4.5 testing -- your help wanted

[Peter Tworek <tworaz666%gmail.com@localhost>]

On 07/23/2011 09:47 AM, Adam Hamsik wrote:
> On Jul,Friday 22 2011, at 9:15 PM, Peter Tworek wrote:
>
>> Hi,
>>
>> I've encountered one problem which seems to be triggered by new gcc
>> version In my spare time I'm working on a Openmoko GTA02 port. It's
>> mostly based on existing evbarm/SMDK2410. I have a kernel and a small
>> ramdisk running on both the device and qemu. With gcc 4.1 everything
>> works as expected. When I've switched to 4.5 I've experienced the
>> following problem. In my ramdisk's /etc/rc I simply execute /bin/sh.
>> When I run it on qemu I see a shell prompt but after I type any command
>> kernel panics.
>>
>> panic: kernel diagnostic assertion "c->c_magic == CALLOUT_MAGIC" failed:
>> file "/home/tworaz/devel/NetBSD/src/sys/kern/kern_timeout.c", line 314
>> Stopped in pid 3.1 (ls) at      netbsd:cpu_Debugger+0x4:        bx      r14
>> db> bt
>> netbsd:panic+0x10
>>        scp=0xc0314560 rlv=0xc03d7f68 (netbsd:kern_assert+0x40)
>>        rsp=0xc27bde2c rfp=0xc27bde40
>>        r7=0xc069cf80
>> netbsd:kern_assert+0xc
>>        scp=0xc03d7f34 rlv=0xc02bb8d0 (netbsd:callout_destroy+0x8c)
>>        rsp=0xc27bde44 rfp=0xc27bde54
>>        r4=0xc1cbbb0c
>> netbsd:callout_destroy+0xc
>>        scp=0xc02bb850 rlv=0xc0291ee4 (netbsd:exit1+0x328)
>>        rsp=0xc27bde58 rfp=0xc27bdeac
>>        r4=0xc27bde64
>> netbsd:exit1+0xc
>>        scp=0xc0291bc8 rlv=0xc02923b0 (netbsd:sys_exit+0x3c)
>>        rsp=0xc27bdeb0 rfp=0xc27bdec8
>>        r7=0x00000001
>> 0
>>        scp=0x00000000 rlv=0xc0326e8c (netbsd:syscall+0x88)
>>        rsp=0xc27bdecc rfp=0xc27bdf58
>> uvm_fault(0xc06a9e44, fffff000, 1) -> e
>> Fatal kernel mode data abort: 'Translation Fault (S)'
>> trapframe: 0xc27bdb20
>> FSR=00000005, FAR=fffffff8, spsr=60000013
>> r0 =0000001e, r1 =c03e8dba, r2 =fffffff8, r3 =00000000
>> r4 =00000000, r5 =c27bdec8, r6 =c0314e90, r7 =e92dd880
>> r8 =00000001, r9 =c27bde98, r10=0000fffb, r11=c27bdba0
>> r12=c27bdab8, ssp=c27bdb6c, slr=c0314128, pc =c020d360
>>
>> Faulted in DDB; continuing...
>>
>> If I use the same ramdisk, but with a kernel compiled using gcc 4.1
>> everything works as expected.
> Please submit PR so this will not get lost and you can submit your patches to 
> openmoko in different PR, too ;)
Done, toolchain/45168. The patches for GTA02 support are still WIP. My
plan is to submit them for inclusion into NetBSD once the device is
actually useful. Of course I can make them available if somebody wants
to play with them in the current form :).

>
>> /ptw
>>
>> On 07/17/2011 01:42 PM, matthew green wrote:
>>> hi folks.
>>>
>>>
>>> GCC 4.5 for most platforms is mostly ready.  the biggest thing missing
>>> at this point is wider testing.  there are still several issues in some
>>> platforms, but many platforms are ready.  i'd like to hear about results
>>> from people building src, xsrc and pkgsrc on these platforms:
>>>
>>>     - i386 [*1]
>>>     - amd64 [*1]
>>>     - powerpc
>>>     - arm
>>>     - armeb [*2]
>>>     - sparc
>>>     - sparc64
>>>     - mipsel
>>>     - mips64el
>>>     - sh3el [*3]
>>>     - sh3eb [*3], [*2]
>>>
>>> [*1] - there are still some uncommited changes here related to eh and
>>>       other handling:
>>>       http://mail-index.netbsd.org/tech-toolchain/2011/07/13/msg001647.html
>>> [*2] - big endian is not tested, but little endian seems fine
>>> [*3] - kernels don't link yet, send me email for a hack
>>>
>>> m68k has issues, and isn't worth dealing with yet unless you're willing
>>> to delve into GCC itself (and if so, please contact tech-toolchain --
>>> right now, the object size is 20+% larger..), alpha and hppa both have
>>> build issues (please build for details), vax mostly builds but requires
>>> a couple of hacks to build (contact me for more details).
>>>
>>> at this point, i'd like to convert x86, sparc, ppc, arm and mips to
>>> GCC 4.5.  before doing this, i'd like to hear reports from others using
>>> GCC 4.5 on these systems, for building the world and for building pkgsrc.
>>>
>>> it's pretty simple.  all you have to do is set HAVE_GCC=45 when building
>>> the system. (eg, ./build.sh -V HAVE_GCC=45).  it's best to ensure a
>>> cleandir before making this switch but it seems that technically only
>>> src/tools/gcc and the destdir need to be cleaned for a build to succeed
>>> (but this will not result in everything being rebuilt with the new
>>> compiler.)
>>>
>>> please let this list know about any success or failure you may have,
>>> including what platform/task/etc you're trying.
>>>
>>> thanks!
>>>
>>>
>>> .mrg.
> Regards
>
> Adam.
>