svn commit: r310045 - head/sys/ddb
John Baldwin
jhb at freebsd.org
Wed Dec 14 01:31:12 UTC 2016
On Wednesday, December 14, 2016 12:18:12 AM John Baldwin wrote:
> Author: jhb
> Date: Wed Dec 14 00:18:12 2016
> New Revision: 310045
> URL: https://svnweb.freebsd.org/changeset/base/310045
>
> Log:
> Use casts to force an unsigned comparison in db_search_symbol().
>
> On all of our platforms, db_expr_t is a signed integer while
> db_addr_t is an unsigned integer value. db_search_symbol used variables
> of type db_expr_t to hold the current offset of the requested address from
> the "best" symbol found so far. This value was initialized to '~0'.
> When a new symbol is found from a symbol table, the associated diff for the
> new symbol is compared against the existing value as 'if (newdiff < diff)'
> to determine if the new symbol had a smaller diff and was thus a closer
> match.
>
> On 64-bit MIPS, the '~0' was treated as a negative value (-1). A lookup
> that found a perfect match of an address against a symbol returned a diff
> of 0. However, in signed comparisons, 0 is not less than -1. As a result,
> DDB on 64-bit MIPS never resolved any addresses to symbols. Workaround
> this by using casts to force an unsigned comparison.
I am somewhat unsure of why this worked on other architectures. amd64
treated ~0 as 0xffffffff which when assigned to a 64-bit register was
zero-extended. i386 also used 0xffffffff, but it used an unsigned comparison
(jae instead of jge). The kernel linker API returns an unsigned long for
the diff, so I do think using db_addr_t for this type is probably the right
solution in the long term.
> Probably the diff returned from db_search_symbol() and X_db_search_symbol()
> should be changed to a db_addr_t instead of a db_expr_t as it is an
> unsigned value (and is an offset of an address, so should fit in the same
> size as an address).
Also, in case it wasn't clear, this fixes resolution of addresses to names
in MIPS64 stack traces in DDB as well as when using 'x', etc.
--
John Baldwin
More information about the svn-src-all
mailing list