Date: Thu, 27 May 2010 20:59:46 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= <phcoder@gmail.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-mips@freebsd.org Subject: Re: Fix mips64 ddb backtracing Message-ID: <4BFEC122.9040307@gmail.com> In-Reply-To: <20100527.100314.539398516089941831.imp@bsdimp.com> References: <4BFDA036.7080502@gmail.com> <20100527.100314.539398516089941831.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
>
> =20
Nothing except my ignorance. Is there already a kdbpeek for 64-bit
quantities? AFAIU one needs to go through kdbpeek for all reads.
> : +}
> : =3D20
> : /*
> : * 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.
>
> =20
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.
>
> =20
Isn't long guaranteed to be at least as long as void * ? Anyway I'm ok
with %jx
--=20
Regards
Vladimir '=CF=86-coder/phcoder' Serbinenko
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BFEC122.9040307>