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