On Fri, Nov 03, 2006 at 01:08:27PM -0800, Dan Mick wrote: > I notice, recently, in Nevada builds, on x86, that the standard workaround > for ::print cpu_t, namely ::print unix`cpu_t, no longer works to print the > final machcpu_t portion of the struct. > > Never really been clear on why the workaround worked, so I haven't delved > into why it's stopped; could someone familiar with type resolution perhaps > give a rough overview of the process? It's awfully nice to see those > fields without standing on your head to typecast or calculate addresses.
It's a result of my fix for "cpu_t hack doesn't work". Now unix module doesn't have a separate copy of cpu_t, it will go back to using genunix's, which only has the forward. In theory it's not hard to fix, I believe we'd have to make mdb_ctf_type_resolve() iterate through all the ctf's for each module. Bug ID, btw, is: http://monaco.sfbay/detail.jsf?cr=4916519 john
