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

[Petr Machata]

Sedat Dilek <sedat.dilek at gmail.com> writes:

> Attached as 0001, please comment.
> Attached as 0002, please comment.

That's fine, thank you.  I pushed both to master.

>>>>> [ 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?

Interesting.  The include changes that I did in that commit must have
resolved the compilation error that you were seeing.

Inclusion guards are #ifndef/#define/#endif lines around the body of a
header file that prevent compilation errors should the file be included
twice.  https://en.wikipedia.org/wiki/Include_guard

>>>>> 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.

Using older kernel should not be a problem, as far as it supports
PTRACE_O_TRACEFORK et al. that we use in ltrace.  All of those come from
Linux 2.5.

Because newer kernels don't change semantics of existing system call
numbers, we only ever need to add to the list in syscallent.h.  When you
run such ltrace on an old kernel, all that happens is that the newer
entries are never used.

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

I don't think you need a C++ runtime library purely to run ltrace.  You
will miss demangling support if you don't have a demangling function in
either of libstdc++, libsupc++ and libiberty, and one of the test cases
(which tests demangling) will fail.  But the core should work either
way.

Thank you,
PM