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

[Sedat Dilek]

On Mon, Sep 3, 2012 at 12:29 PM, Petr Machata <pmachata at redhat.com> wrote:
> 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.
>

Thanks for pushing them!

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

OK, I used "inclusion guards" several times by not knowing the correct
technical term.

Maybe, you can explain when there has to be chosen "ifdef" and when
"if defined" :-)?

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

OK, so that makes the Freetz hack (regenerating hdr-files) obsolete?

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

OK, I have in my config.log...

ac_cv_lib_iberty_cplus_demangle=no
ac_cv_lib_stdcpp___cxa_demangle=yes
ac_cv_lib_supcpp___cxa_demangle=yes

...which produces warnings in my build-log towards libsupc++ and
libstd++ (.la) files.

I have disabled demangling support now in my ltrace,mk file:

+# Disable demangling support
+$(PKG)_CONFIGURE_ENV += ac_cv_lib_iberty_cplus_demangle=no
+$(PKG)_CONFIGURE_ENV += ac_cv_lib_stdcpp___cxa_demangle=no
+$(PKG)_CONFIGURE_ENV += ac_cv_lib_supcpp___cxa_demangle=no

That kills the above mentioned warnings.

[ MIPS PLT support ]

BTW, "--no-plt" ltrace CLI-option does not work here on MIPSEL.
I see in my generated configure-line "-with-mips-plt".

While investigating the issue by comparing MIPS "arch.h" with the one
from other archs, I fell over this:

"PLTs_INIT_BY_HERE" and "E_ENTRY_NAME" is no more used in the ltrace-sources!

Furthermore, I see in "options.c":

53:#ifdef PLT_REINITALISATION_BP
56:char *PLTs_initialized_by_here = PLT_REINITALISATION_BP;

So, is the below fix OK?

[ make/ltrace/patches/fix-mips-plt-support.patch ]
--- sysdeps/linux-gnu/mipsel/arch.h.orig        2012-09-03
12:13:22.000000000 +0200
+++ sysdeps/linux-gnu/mipsel/arch.h     2012-09-03 18:00:32.941945491 +0200
@@ -31,8 +31,7 @@
 #define LT_ELFCLASS    ELFCLASS32
 #define LT_ELF_MACHINE EM_MIPS

-#define PLTs_INIT_BY_HERE "_start"
-#define E_ENTRY_NAME    "_start"
+#define PLT_REINITALISATION_BP    "_start"

 #define ARCH_HAVE_LTELF_DATA
 struct arch_ltelf_data {
- EOP - (End Of Patch)

Shall any PLT defines be eliminated?

Is it possible to disable MIPS PLT support?
Would that mean to drop "plt.c" file from "configure{.ac}" and/or
"Makefile.{in,am}" (sorry, didn't check the code)?
I tried to pass "-without-mips-plt" as a configure-env-variable but
that seems not to work.

Adding "#define ARCH_HAVE_ADD_PLT_ENTRY" in MIPS "arch.h" breaks.

I know I have a lot of question :-).

/me still has no glue about demangle or PLT support at all (if you can
give a brief introduction?)

Regards,
- Sedat -

> Thank you,
> PM

P.S.: Does there exist an IRC support-channel #ltrace or #ltrace-devel
(Freenode/OFTC)?