Fwd: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]

[James Carlson]

James C. McPherson writes:
> We're requesting a release binding of micro. There's no intention
> of pushing this back into Solaris 10.

Oh.  There aren't any Micro releases on the horizon, so that's a
little confusing.

Using that binding means "Nevada only" for now, the same as a Minor
release binding.

> > There are some cases where it is inconsistent about it's use of
> > synthetic instructions -- this one gets very hard to nail down without
> > access to the current source.  For example, 'not' is only emitted in
> > certain cases, even when it would be correct in others.  I just opted
> > to emit 'not' whenever the conditions were correct, instead of trying
> > to figure out which permutations happened to get 100% same behavior.

I would consider the specific instruction decoded in any given case
(where there are reasonable and "legal" [per SPARC documentation]
variants) to be "Not an Interface" in ARC terminology.  It's visible
and interesting behavior to users, but not something that's documented
or that anyone could expect to rely on.

> > version (as opposed when it's built for kmdb), it supports the setting
> > of an environment variable _LIBDISASM_DEBUG that can cause information
> > about the instruction decoding to be sent to stderr as well as control
> > the use of synthetic instructions.  I'm not sure what would an
> > appropriate classification if this is something that needs to be
> > documented.

That's also undocumented, and looks like a Project Private detail.

> Re the ARC-visibility, my understanding was that we
> needed a fasttrack due to moving from closed to open.
> I'm quite happy to be mistaken on that front!

Not so.  Neither location of the source in the tree nor the license
applied are generally architectural issues.

With a Micro or Minor binding, I think this one is simplest of cases.

(Even with a Patch binding, I think it's fairly reasonable.  I can
understand, though, why it's not interesting as a patch.)

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677