[Ltrace-devel] ltrace: Try to fix MIPS arch (tested against git-fcf256c)

Sat Sep 1 17:23:37 UTC 2012

On Sat, Sep 1, 2012 at 3:59 PM, Petr Machata <pmachata at redhat.com> wrote:
> Sedat Dilek <sedat.dilek at gmail.com> writes:
>
>> On Sat, Sep 1, 2012 at 2:15 AM, Petr Machata <pmachata at redhat.com> wrote:
>>> Sedat Dilek <sedat.dilek at gmail.com> writes:
>>>> [ handle_event.c ]
>>>>
>>>> Fix "pred" uninitialized in pending_new_remove().
>>>
>>> That should go into a separate patch.  It's a good catch, but
>>> conceptually has nothing to do with cleaning up MIPS.
>
> This should be one patch.
>

Attached as 0001, please comment.

>>>> [ breakpoints.c ]
>>>>
>>>> MIPS arch has no own "breakpoints.c".
>>>> IIRC sth, was wrong with "list_of_symbols" in
>>>> enable_all_breakpoints()... "Process" has no member "list_of_symbols",
>>>> so cut off the mips-ifdef part.
>>>> Just testing compiles or not.
>>>
>>> Cutting this actually seems reasonable.  There was a similar ifdef for
>>> PPC, and that is now gone as well (and PPC works fine).  I believe
>>> ltrace now handles delaying breakpoint enablement.
>>>
>>>> [ handle_event.c ]
>>>>
>>>> Same as for breakpoints.c cut off the mips-ifdef, seen
>>>> "list_of_symbols" errors in handle_breakpoint().
>>>
>>> Hmm, that seems like an implementation of the delayed start.  I think
>>> this can be removed as well, with the same rationale as above.
>
> These two should probably be in a patch by themselves.
>

Attached as 0002, please comment.

>>>> [ ltrace-elf.h ]
>>>>
>>>> Unfortunately, the ARCH_HAVE_LTELF_DATA defined in
>>>> "sysdeps/linux-gnu/mipsel/arch.h" is somehow not recognized.
>>>> Restore the mips-ifdef part thrown out in struct ltelf {}.
>>>> See commit e67635d6dcec ("Move arch-specific bits from ltrace-elf.c to
>>>> PPC and MIPS back ends") for more details.
>>>
>>> This is not acceptable.  If what you are seeing is redefinition error,
>>> then arch.h might be included twice.  Note that it has no inclusion
>>> guard.  The proper way to fix this is to put inclusion guards to that
>>> file.
>
> And this too.  (That's three already, so yesterday I miscounted.)
>

Can you explain what you mean by "inclusion guards"?

Against ltrace-a7e7bea I could compile with the above two commits.
So, this issue seems to be eliminated?
Or how can I prove it is OK or not?

>>>> As a bonbon I added syscallent.h.diff (signalent.h.diff was empty).
>>>
>>> That should also go to a separate patch.
>>
>> That highly depends on the target's Linux kernel version (see attached
>> linux-2.6.13.1_syscallent.h.diff, the previous one was linux-2.6.32).
>
> Yes, it does, but newer kernel versions never change meaning of older
> system call numbers, so it's always safe to apply an update.  I
> regenerated syscallent.h from latest kernel tree, that has a couple more
> system calls still, and that is now on master.
>

Can't say what happens with ltrace against a very old Linux-2.6.13.1
and not doing the Freetz pre-configure modifications.

-rw-r--r-- 1 wearefam wearefam 13046 Sep  1 19:02
./source/target-mipsel_uClibc-0.9.32.1/ltrace-a7e7bea/sysdeps/linux-gnu/mipsel/syscallent.h
-rw-r--r-- 1 wearefam wearefam 15852 Sep  1 19:02
./source/target-mipsel_uClibc-0.9.32.1/ltrace-a7e7bea/sysdeps/linux-gnu/mipsel/syscallent.h.orig

> I'm looking into this a bit, and it appears that the whole MIPS
> situation is a fair deal of mess.  MIPS is endian switchable.  There is
> currently one piece of code in ltrace that asks about endian, and that
> is in lens_enum.c.  It would be best if we could rewrite it to work
> either way.  Then we could drop the #define ARCH_ENDIAN_* stuff that I
> put in some time ago.  Unless we want to support tracing MIPSel binaries
> with MIPSeb ltrace (or the other way around), I don't believe we need to
> burden ourselves with the endian business.  If we want to, then current
> measures are insufficient anyway.
>
> Then there are three ABI's (o32, n32, 64), I thought only Irix did this.
> That means we need syscallent1.h as well, for the 64-bit cases (n32,
> 64).  But because syscall numbering is disjoint, it would lead to a
> sparse array, and while it might work, it would be not very efficient.
> We will be in pretty much the same situation with the new x86 ABI "x32",
> and some support for this will have to land one way or another.
>
> It is apparent that current MIPS back end only cares about o32.  I
> suppose that's the more common case, as most "small" devices (routers et
> al.) will just have 32-bit CPU.  Personally I would like to see proper
> support of 64-bit (n32, 64) ABI's as well.
>

I can't say much to that described problems on MIPS - this is more for
the experts.

> So, that's for sometimes.
>

You happen to know if I need libstdc++ or is uClibc++ enough?
Any minimum requirement to these stuff?
Linux kernel minimum version etc.?

I will try to flash on my router and see.

> Thank you,
> PM
-------------- next part --------------
rm -f -r source/target-mipsel_uClibc-0.9.32.1/ltrace-a7e7bea
rm -f -r packages/target-mipsel_uClibc-0.9.32.1/ltrace-a7e7bea
rm -f packages/target-mipsel_uClibc-0.9.32.1/.ltrace-a7e7bea
rm -f -r packages/target-mipsel_uClibc-0.9.32.1/ltrace-a7e7bea; rm -f packages/target-mipsel_uClibc-0.9.32.1/.ltrace-a7e7bea;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-handle_event.c-Fix-error-pred-uninitialized-in-pendi.patch
Type: application/octet-stream
Size: 883 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20120901/ff7b75c1/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-breakpoints.c-handle_event.c-Fix-compilation-on-MIPS.patch
Type: application/octet-stream
Size: 3362 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20120901/ff7b75c1/attachment-0005.obj>
-------------- next part --------------
---> package/ltrace: preparing... tools/gunzip -c dl/ltrace-a7e7bea.tar.gz | tar -C source/target-mipsel_uClibc-0.9.32.1 -x
set -e; shopt -s nullglob; for i in make/ltrace/patches/*.patch; do tools/freetz_patch source/target-mipsel_uClibc-0.9.32.1/ltrace-a7e7bea $i; done
    applying patch file make/ltrace/patches/0001-handle_event.c-Fix-error-pred-uninitialized-in-pendi.patch
    patching file handle_event.c
    ----------------------------------------------------------------------
    applying patch file make/ltrace/patches/0002-breakpoints.c-handle_event.c-Fix-compilation-on-MIPS.patch
    patching file breakpoints.c
    patching file handle_event.c
    ----------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltrace-precompiled.txt.xz
Type: application/octet-stream
Size: 6192 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20120901/ff7b75c1/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltrace-precompiled.txt.xz.sha256sum
Type: application/octet-stream
Size: 91 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20120901/ff7b75c1/attachment-0007.obj>