Re: [Valgrind-developers] Re: lazy EIP updating sorta working (xedit runs!)

[Jeremy F. <je...@go...>]

On Wed, 2002-12-04 at 12:52, Julian Seward wrote:

> On contemplation, that solution seems to be good to me.  It would more or
> less remove the flag-move overhead for the bog-standard ALU ops -- those
> which set exactly OSZACP.   Inc, dec, neg and not will still have to go
> via the expensive route, but hopefully they are not so common.

Yes.  From looking at generated code, INC and DEC are the only even
vaguely common instructions which hit this, and they aren't that common.

Separating out D was reasonably easy.  It complcates the implementation
of GETF/PUTF, but those are very rare (they're only used for pushf/popf,
and I couldn't find any instances of those being used in real programs;
I had to write a specific test; I guess that's why they're implemented
so slow in real silicon).

> I'm trying to approach a new-code freeze for 2.0.  I'd like to take 
> 44-symbolic-addr and its dependent 45-memcheck-symaddr.  How stable
> is 44 -- is it good enough to ship? 

It works for me.  The main limitation is the lack of DWARF2 support.  I
looked at it the other day, but it is fairly complex (I'll need to
implement or steal a forth interpreter for it).  Oh, there is a #define
LAZYSIG 1 which should probably be 0 (it affects whether SIGSEGV is
caught for the whole tracing process or just for each pointer
dereference - at present it is disabled all the time, but this means
that any bugs turn into a silent sulk rather than a useful symptom).

> If this flags stuff can be bought to successful conclusion within the 
> next week or so, that would be great to ship too.

That's what I'm currently working on.  I think there's an issue around
string ops (which UInstrs are supposed to change Simd flags, and which
aren't?), but I'll send something more detailed later.

        J