On 3/6/06 11:54 AM, "Dave Anderson" <anderson(a)redhat.com> wrote:
Not off-hand...
It's a "known issue" that I've gotten around it by, starting at the
virtual
addresses
after the ud2a, running multiple new "dis" attempts at each successive address
until it makes sense. It's strange, sometimes nothing really needs to be done
because it shows just a couple instructions as bogus, but then "gets back on
track", while other times it never gets back in sync with the real
instructions.
Ideally it should be handled in the gdb code, which is what's screwing it up.
Crash is just taking the gdb disassembly output and running it through a
per-processor-type filter function to improve what you get from gdb.
Dave
--
I will resort to using dis in that matter to get around it, and pass that on
to the level 2 people here who will possibly run across this working
customer issues.