Re: test case bin3 failed in my x86_64 box

[Martin Hunt <hunt at redhat dot com>]

On Fri, 2006-04-28 at 09:52 -0400, 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?

The only tapset that would set endianness would be one that contains
functions to write out a particular binary format. If you were to have
two of those tapsets, with different default endianess, and you mixed
calls to them, then yes, what you describe would happen, but that sounds
extremely far-fetched. 

> > [...]  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.

Exactly.

> > 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?

Run script, collect data. Use a GUI tool or some kind of script to
analyze the collected data.  What if you do this on a SPARC then later
use the same script to collect data on an x86 box?  The analysis is done
on the SPARC. You will find all the data is the wrong byte-order. So you
have to edit every print statement to set each format string to the
correct order? So we just eliminate native binary printf to save people
from doing this to themselves? I can easily imagine a scenario where
native is always wanted.  A global endianess switch seems the logical
solution to these kinds of problems.