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

[James C. McPherson]

Jason King wrote:
> Missed you on the CC..
> 
> ---------- Forwarded message ----------
> From: Jason King <jason at ansipunx.net>
> Date: Sep 5, 2007 5:29 PM
> Subject: Re: Unencumbered libdisasm for Sparc [PSARC/2007/507 Self Review]
> To: Bill Sommerfeld <sommerfeld at sun.com>
> Cc: Alan Hargreaves <ah89892 at sac.sfbay.sun.com>
> 
> 
> On 9/5/07, Bill Sommerfeld <sommerfeld at sun.com> wrote:
>> I don't see a statement of interface stability or a release binding
>> (Minor?  Patch?)
>>
>> The only thing that makes this arc-visible is the fact that there are in
>> fact some minor changes to the instruction decoding; replacing one
>> implementation with another that behaves exactly the same is a
>> non-event.  So something changed but the case is silent on this...
>>
>> I would have expected a brief summary of the discussion on
>> opensolaris-code as part of the case materials.
> 
> I don't have the necessary background on Sun's policy for release
> bindings to state what the appropriate answer would be, nor to comment
> in the interface stability.  I would suspect  for the interface
> stability at least, it would match whatever the current classification
> for the current library is.


We're requesting a release binding of micro. There's no intention
of pushing this back into Solaris 10.


> As for changes, there are a few cases where the current closed source
> bin outputs incorrect output (unfortunately, the sparc system I have
> been using for testing is unavailable at the moment, so I cannot give
> specific binaries for examples right now, though I can comment on the
> errors themselves).  I have not carried those forward.
> 
> 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.
> 
> Would documenting which synthetic instructions are emitted, as well as
> which instructions the current library outputs incorrectly satisfy any
> ARC requirements?
> 
> As for interfaces, I also don't have any way to know if there are any
> existing undocumented interfaces that otherwise might change.  The one
> thing I guess might be considered a new interface is in the .so
> 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.
> 
> Just let me know what needs to be done.


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!



James C. McPherson
--
Senior Kernel Software Engineer, Solaris
Sun Microsystems