[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