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

Petr Machata pmachata at redhat.com
Mon Jan 26 16:54:04 UTC 2015


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

> As far as the linker code for MIPS is concerned I don't even see a
> single jump. Any atomic sequence that has a branch can be written as 2
> shorter sequences with the branch decision performed earlier. Besides,
> we always want atomics to be as short as possible. So no, I don't
> expect this to come up in practice.

That's what I would expect.  I suppose whoever implemented this for GDB
just found some code with a jump in there, but really I have no idea
where this comes from.

> Perhaps, I wasn't clear earlier. My intention is just to remove the
> check for (nr <= 2) from mips_next_pc(), not to allow more than 2
> breakpoints as a general case. Since the existence of more than 2
> breakpoints is eventually checked by sw_singlestep_add_bp(), enforcing
> the limitation in mips_next_pc is not strictly necessary. So the
> options are:
> 1. keep the atomic sequence logic in arch_sw_singlestep(), as it is currently for PPC
> 2. move atomic logic to mips_next_pc() and remove the restriction on (nr <= 2) from mips_next_pc()

Oh, I see now.  I think the PPC way is a bit better, in that it doesn't
encode the upper limit and relies purely on lower-level callbacks.  But
ultimately do whatever makes sense to you.  Just don't overflow newpcs
array if you decide to go the mips_next_pc way.

This check is already problematic:

	if (nr <= 0 || nr > 2)
		goto fail;

If nr really is > 2, then we are in the domain of undefined behavior
anyway, and the compiler is free to optimize this away.

Thanks,
Petr



More information about the Ltrace-devel mailing list