[Ltrace-devel] serious problem when running ltrace on an ARM board

[Petr Machata]

Honggyu Kim <honggyu at aces.snu.ac.kr> writes:

> I'm currently trying to use ltrace on my ARM board.
> I found that ltrace works on many Linux systems running on ARM as well
> from README doc.
> However, Itrace seems not to be running on my ARM board.
> The problem is that it often generates "Segmentation fault".
> The meaning of "often" is that it doesn't work deterministically, which
> is very weird.
> It sometimes works fine and sometimes crashes.
> To give better understand, I will show you the result below.

It's not all that weird in that landscape.  There may be races,
sometimes the process wakes up a bit earlier, signals arrive in
arbitrary order, and this all changes the behavior.  Ideally, ltrace
would handle all this, but, well, there are bugs.

> a. a tegra board(dual core) with ubuntu linux (ltrace downloaded from
> apt-get package manager)
> b. SMDK210 board(dual core) with android linux (ltrace ported by me)
> c. qemu emulator(single core) with android linux (same version as 'b')

I seem to recall trying to run one of the recent trunks in qemu and on
smartQ machine.  I also have trimslice, and I _think_ I tried ltrace on
that, but I'm not sure.  Anyway, I remember having seen the testsuite
pass.  There may have been a failure or two (parameters.exp would be a
candidate), but nothing serious.

Hmm, what do you mean by "ltrace ported by me"?  Did you need to patch
ltrace to compile it?  What were those changes?

> From my test result, 'a' and 'b' often crash the execution and the
> result is not deterministic.  However, 'c' works fine without any
> problems. This makes me very confused.

Is this the same OS?  I seem to recall there were different ABIs, like
hard-float, thumb modes, etc. etc.  I only have the vaguest of ideas of
ARM internals, so I may be confused at that point.  But perhaps the
problem was in that what you booted in qemu was somehow better supported
(by ltrace) than the real thing.

> I'm just wondering if we have to flush instruction cache after
> modifying code section using PTRACE_POKETEXT Thanks in advance for
> your any kind of help.

I don't know.  I would expect the hardware to take care of that.  Do you
know whether ARM has knobs for this (the cache flushing), and whether
Linux kernel knows how to push them?

PM