test case bin3 failed in my x86_64 box

[Vara Prasad]

Frank Ch. Eigler wrote:

>hunt wrote:
>
>  
>
>>>More than that: set_endian being an ordinary function call, one can
>>>imagine separately authored tapset probes to fight over it.
>>>      
>>>
>>We cannot and should not attempt to prevent programmers from writing
>>nonsense. All we can do is make sure it is harmless nonsense.
>>    
>>
>
>The problem in this scenario is that two independent programmers may
>set conflicting "default" endianness in their respective tapsets, and
>a script may pull both in.  Who in this picture is writing "nonsense"?
>How should they have known?
>
>  
>
>>[...]  I am guessing from "whims of script code" you expect the user
>>will have a better idea of what endianess to write binary data
>>in. Why?
>>    
>>
>
>I was guessing one usage scenario: that a user wants to feed in a
>binary trace stream to an analysis tool of her choice.  She knows what
>format the tool expects, and thus informs systemtap of its required
>endianness.
>
>But this scenario doesn't make much sense.  Unless systemtap prints
>out metadata, a generic trace tool will have enough problem just
>parsing the data into records, never mind decoding the endianness.
>
>  
>
>>I expect binary data to be used when the script must output an
>>exactly formatted binary file, and the endianess is not something
>>that the user should be able to change.
>>    
>>
>
>If so, and if a particular forced endianness is required, why not have
>the tapset script use the explicit-endian formatting directives?  Just
>to save typing on those "-"/"+" sign?  Is that worth the risk of
>interference from unforseen probes that have the opposite idea?
>
>Anyway, this subject could use more background: what did you guys have
>in mind with respect to the overall end-to-end flow of data?  What
>program is to read this data?  How?  Why expect it to have problems
>with (say) native endianness?
>
>
>- FChE
>  
>

Sorry to join the party late, but i think tapsets should not implement 
endianness and i also think tapsets should stay away from binary printf 
as much as possible.  In other words in my view tapsets should be as 
much platform independent as possible unless the tapset is platform 
specific.

Coming to endianness for a script i think we should support script wide 
option at compile time as i am not finding need for one statement in a 
script to output big endian and other statement to output little endian. 
I think this is not a problem for us to supporting pre-compiled modules 
in the future, as we don't expect them to be portable across platforms.

Hien's question able to analyze the data produced on one platform using 
tools on another i think it is a good feature but not necessarily a high 
priority in my view.

bye,
Vara Prasad