This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] [i386] Put hlt at the ON_STACK breakpoint [Re: GDB 7.4.91 available for testing]

> A valid instruction is not enough. We need a valid instruction
> that will cause Valgrind to terminate block translation.
> The breakpoint trap instruction is ok for that.
> (0xcc for x86 and amd64, 0x0005000d for mips32).

I think it is fine to update GDB to insert the breakpoint instruction
instead of leaving random bytes at the breakpoint location. But it
sounds like this is forcing GDB to have insider knowledge of valgrind.
It would seem better if, in parallel to our efforts, something was
done on the valgrind side as well to make it work without the GDB
workaround. For instance, couldn't valgrind figure out that the
block translation should stop at a Z0 address if the instruction
underneath is illegal?

What I am trying to do, is make sure that new GDB versions work well
with older versions of valgrind (although, isn't gdbserver support
relatively recent?), while at the same time trying to make future
versions of valgrind more robust. I don't know how long we are going
to be able to keep the workaround. What if other tools implementing
the remote protocol had the same problem, and they required us to
insert a different instruction instead?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]