Re: abi

[John L. <le...@mo...>]

On Mon, Oct 14, 2002 at 04:32:38PM -0400, graydon hoare wrote:

> Perhaps I was a bit too generous saying it adds "no" complexity; but the
> complexity it adds is small. Nothing fundamental about libdb's i/o is
> altered: after the first 64 bytes the file is byte-for-byte exactly the
> same as it was. I just add a small header and a write/check pair for
> that header. I don't think of this as a major penalty, but of course you
> may differ in opinion on that.

The code failed my "do I understand this immediately" test. When
something fails that test, it means it has a much higher hurdle to prove
its worth.

> I'm not suggesting any code for "reading non-native structures" go into
> libdb. You're right, that's yucky stuff that belongs in an "op_import"
> tool. I'm merely asking that libdb be changed so that it always
> describes the type of file it's producing. I want to avoid the situation
> where I've got a file in my hands of *unknown* binary structure.

When would that happen and why ? It is such a borderline case: you would
have to have your hands on a non-exported sample file that you have lost
all context to. It's not worth catering for.

> In your scenario, you can get this:
> 
> $ oprofpp -l /usr/bin/emacs
> segmentation fault (core dumped)

Only if :

a) the user has fucked up somehow and is mixing non-native binaries for
their system. I don't care about the user fucking this up: they should
recompile oprofile and install it properly.

b) the user is incapable of running op_export. What circumstances can
this happen under ? The most obvious I can think of is ABI bugs, which
as I've said, applies in both cases anyway.

> copy of the oprofile tools which produced the sample and run op_export
> and work off the result of that, and that might involve going back to
> the customer. That's what we're trying to insulate against.

Sorry, I'm not that interested in your customers unless the resultant
feature is generally useful and does not uglify the source. This code
fails both tests.

A separate op_export passes both.

With a separate op_export, you can still have op_export --show-abi - the
exact same information is STILL available to you if you really come
across an ABI bug. You need two pieces of information - the original
sample file, and the native ABI of the remote machine. All you are
proposing is to commingle (I love that word !) the two all the time,
rather than just when needed.

regards
john

-- 
"That's just kitten-eating wrong."
	- Richard Henderson