[Ltrace-devel] [PATCH] Tracing PLT-less MIPS binaries

[Petr Machata]

Faraz Shahbazker <Faraz.Shahbazker at imgtec.com> writes:

> On 01/21/2015 02:44 PM, Petr Machata wrote:
>> So it seems to me this logic should be folded into mips_next_pcs, and
>> only activated when the stepped-over instruction is an LL.
> ... 
>> I think ltrace currently support two breakpoints for software
>> singlestep.  So you put one just after the SC, and one extra is
>> available for when there's a jump between LL and SC.  If there are more
>> jumps, we just don't have a good answer for that.  PowerPC just gives up
>> and returns SWS_FAIL, which should at least clean up things and get
>> ltrace into the right states. 
>
> PPC sets breakpoints at branch destination for all branches within the
> atomic sequence and relies on the call-back to handle more than 1
> jumps as an error. If we fold the atomic logic in to mips_next_pc,
> we'd have to remove checks on (nr <= 2) from mips_next_pc and allow it
> to return more than 2 addresses. Does this sound reasonable?

IIRC, the limit of 2 is taken from GDB, where the PPC
software-singlestepping code is lifted from.  I think it's arbitrary,
very probably it's just empirical upper bound of code found in practice.
Clearly in theory, there can be more than one jump between LL and SC,
but does it come up in practice at all?

If yes, not only the MIPS backend would have to be changed, but the core
as well.  The sofware-singlestepping brakpoints would have to be kept in
a vector probably, instead of a simple array.  It's more book-keeping
and more code.

So if you tell me that's necessary, I can probably find a bit of time to
adapt the core--or you can do it and I'll review your patch.  We'd then
want to be careful to add test cases for it.  It's a messy part of
ltrace, and this use case comes up rarely enough that it might get
broken without anyone noticing.

>> makes me think, what if I have a code like this (pardon pseudo-assembly,
>> I don't actually speak MIPS ;) )
>> 
>> 	JMP xyz
>> 	LL
>> 	... etc ...
>> xyz:
>> 	SC
>
> I can't find the relevant spec for whether this is valid, but gcc does
> not allow LL in a delay slot; it will always insert padding after the

OK, then disregard this.

> jump. Anyway, if this was allowed, there would be no way to handle it
> while single stepping. PC never actually points to the instruction in
> the delay slot so there would be no way to determine the beginning of
> the atomic sequence except by explicit inspecting PC+4, while
> inspecting the branch instruction.

My idea was to inspect PC-4 when stepping over LL, but I admit that I
don't know if it would work.

Anyway, that's now moot.

Thanks,
Petr