[Ltrace-devel] [PATCH v2 0/8] MIPSEL o32 updates

[Sedat Dilek]

On Thu, Sep 27, 2012 at 7:19 PM, Petr Machata <pmachata at redhat.com> wrote:
> edgar.iglesias at gmail.com writes:
>
>> From: "Edgar E. Iglesias" <edgar at axis.com>
>>
>> This is the series I've been hacking on.
>
> I pushed this to master.  Thanks for all the work!
>

Hi,

nice to see there is more progress on MIPS(el) :-).

I have tested ltrace 0.7.0-git3a1806d against the Freetz build-system.
Target-host: MIPSEL 32-bit
Build-host: Ubuntu/precise AMD64.
Toolchain: gcc-4.7.2-RC-20120914 + uClibc-0.9.33.2 + binutils-2.22
(for more see [1]).
Contents of attached tarball:
* ltrace-0.7.0-git.diff (patch against Freetz build-system)
* make_ltrace-precompiled.txt (build-log of ltrace Freetz package)
* ltrace-L-x-main-debug-71.txt (debug-output)
* LTRACE_DEBUG_SESSION (Mini-Howto)

Can you please have a look?

Regards,
- Sedat -

[1] http://freetz.org/browser/trunk/toolchain/make/target

>> There are still issues with threaded apps.
>>
>> There are at least two issues:
>> 1. Singlestepping over breakpoints is not really thread safe, IIUC.
>
> FWIW, Linux backend takes care of this.  We stop all threads before
> singlestepping.  That holds also when arch uses software singlestepping.
>
> The logic for that is declared in sysdeps/linux-gnu/trace.h and
> implemented in the corresponding .c, and can be reused by an arch
> backend when deemed necessary.  PPC backend does that.
>
>> 2. Waiting until function return until adding breakpoints to
>>    resolved addresses is to late and not thread safe.
>>
>> I plan to take a closer look at the watchpoint approach to eliminate nr 2
>> as Petr M suggested. Any suggestions on howto solve issue nr 1 are also
>> wellcome. Leaving the breakpoint inplace and emulating the insn might be
>> a last resort, but quite involved...
>
> Yeah, GDB calls this displaced stepping.  This would be an interesting
> optimization--process under ltrace can perform pretty horibly, with all
> the context switches and singlestepping, and this would help a bit.  But
> it shouldn't be necessary from strictly the correctnes point of view.
>
> Thanks,
> PM
>
> _______________________________________________
> Ltrace-devel mailing list
> Ltrace-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: for_pmachata.tar.xz
Type: application/octet-stream
Size: 21168 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20120927/c2018f18/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: for_pmachata.tar.xz.sha256sum
Type: application/octet-stream
Size: 85 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20120927/c2018f18/attachment-0003.obj>