Fix mips64 ddb backtracing

Vladimir 'φ-coder/phcoder' Serbinenko phcoder at gmail.com
Thu May 27 18:59:55 UTC 2010


M. Warner Losh wrote:
> : +static inline register_t
> : +kdbpeekD (uintptr_t addr) {
> : +#ifdef __MIPSEL__
> : +	return ((register_t) kdbpeek ((int *) addr))
> : +		| (((register_t) kdbpeek ((int *) addr + 1)) << 32);
> : +#else
> : +	return ((register_t) kdbpeek ((int *) addr + 1))
> : +		| (((register_t) kdbpeek ((int *) addr)) << 32);
> : +#endif
>
> This seems wrong.  What's wrong with reading the 64-bit quantity
> directly?
>
>   
Nothing except my ignorance. Is there already a kdbpeek for 64-bit
quantities? AFAIU one needs to go through kdbpeek for all reads.
> : +}
> : =20
> :  /*
> :   * Functions ``special'' enough to print by name
> : @@ -140,7 +150,7 @@
> :  	}
> :  	/* check for bad SP: could foul up next frame */
> :  	/*XXX MIPS64 bad: this hard-coded SP is lame */
> : -	if (sp & 3 || sp < 0x80000000) {
> : +	if (sp & 3 || (uintptr_t) sp < 0xffffffff80000000ULL) {
>
> This is wrong.  sp should be cast to intptr_t to have it still work
> with 32-bit debugging.  Unsigned sp will be 0x80000000, which will
> trigger this case.
>
>   
I noticed it myself. Should be fixed in new patch.
> : -			(*printfn)("%x", args[j]);
> : +			(*printfn)("%lx", (unsigned long) args[j]);
>
> These casts aren't right.  We should likely be using intmax_t here and
> %j.
>
>   
Isn't long guaranteed to be at least as long as void * ? Anyway I'm ok
with %jx


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko




More information about the freebsd-mips mailing list