Re: Bug in NetBSD compiler or "bus.h" header file crashes my ISDN4BSD

[Andrew Doran <ad%netbsd.org@localhost>]

On Sun, Mar 16, 2008 at 02:19:39PM +0100, Hans Petter Selasky wrote:

> Summed up:
> ==========
> 
> It appears that because the bus_space_xxx functions are implemented like 
> macros this can cause errors in the generated code! The following code is 
> excuted when filtering on the "%cx" register:
> 
> hfc4s8s_fifo_write:
> 
> 0xcd71796a:     movw    0xffffffda(%ebp),%cx //0x8
> 0xcd71796e:     shrw    $0x2,%cx //0x2
> 
> ...
> 
> bus_space_write_multi_4:
> 
> 0xcd7179df:     lodsl   (%esi) // valid address
> 0xcd7179e0:     movl    %eax,0(%edx) //valid address
> 0xcd7179e2:     loop    0xcd7179df // uses %ecx, but only %cx was initialised
> 
> I use a 16-bit length variable which I pass to "bus_space_write_multi_4" as 
> the last argument. This is actually the "count". I suspect that somehow the 
> upper 16-bits of the %ecx register never gets initialised --- oops. Is this a 
> bug in the NetBSD compiler or in the "bus.h" header file ?

I don't know which. I will take a look. Note that in NetBSD-current, the
bus_space methods are implememented as assembly stubs on x86 and so don't
have this problem.

(As an aside that should really be done for all platforms because it makes
for significant space savings and hides the implementation details.)

> Full details:
> =============
> 
> First of all. I would like to wish that the NetBSD kernel would load the 
> symbols from kernel modules and resolve these when the kernel panics, hence 
> my software is a kernel module. Anyway here goes:

Do you have the ksyms device configured in your kernel? It should work like
that.
 
> db> bt                                   
> _prop_dictionary_keysym32_pool(c312a000,c312ad94,c2a90938,8,c312a000) at 
> 0xcd717
> 9df
> _prop_dictionary_keysym32_pool(c312ad94,c312a000,cd3f2abc,cd716987,c312a000) 
> at 0
> xcd713fed
> _prop_dictionary_keysym32_pool(c312a000,c312ad94,cd3f2abc,cd7168e9,c312ad94) 
> at 0
> xcd7148a0
> _prop_dictionary_keysym32_pool(c312a000,c312ad94,cd73f828,341,c312a93c) at 
> 0xcd7
> 16987
> _prop_dictionary_keysym32_pool(c312a000,8,3,7,0) at 0xcd715516
> _prop_dictionary_keysym32_pool(c312a000,22bf98,cd3f2b5c,c04390ca,c09c3ac0) at 
> 0x
> cd715c2d
> _prop_dictionary_keysym32_pool(c3116000,0,dd310010,30,c0970010) at 0xcd700075
> Xintr_ioapic_level20() at netbsd:Xintr_ioapic_level20+0x9b
> --- interrupt ---
> Xspllower(0,c09993c4,7,6,c04338c1) at netbsd:Xspllower+0xe
> mpidle(cc8ac2e4,0,0,cc8ac2e4,103) at netbsd:mpidle+0xd7
> preempt(0,4,cc8bde88,8062000,3ff0) at netbsd:preempt+0x5d
> trap() at netbsd:trap+0x6bb
> --- trap (number 3) ---
> 
> The topmost function translates to the following function:
> 
> _prop_dictionary_keysym32_pool(c312a000,c312ad94,c2a90938,8,c312a000)

It's probably resolving the closest known symbol.

Andrew