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

[Petr Machata]

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

> On Mon, Sep 3, 2012 at 12:29 PM, Petr Machata <pmachata at redhat.com> wrote:
>> Sedat Dilek <sedat.dilek at gmail.com> writes:
>> 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" :-)?

My preference is to use #ifdef if possible.  #if defined is used when
you need an expression, like #if defined(THIS) || THAT < X.

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

Depends on what version of ltrace they use and what kernel they use.
Old ltrace might not know about all system call numbers of the kernel
that it is intended to run on.  If that is the case, it is reasonable to
update the syscall list before a build.

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

I removed that option when working on libs branch.  We have -L for that
purpose, and have had for a long time.  That --help entry is a
leftover.  I removed it now, thanks for pointing this out.

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

Yeah, these used to be used for the delayed start.  As mentioned
earlier, this shouldn't be necessary anymore.  I removed it.

I realized that one of the MIPS-related hunks that I acked for removing
was in fact not delayed enablement (which should indeed not be
necessary), but breakpoint reenablement after first call.  The deal is
that PLT entry changes after the first call is made.  (Before the first
call is made, it points to dynamic linker resolver, after the first call
it points directly to the target function.)

The old trick that PowerPC (and MIPS) used is that after the first call
returns, we check if breakpoint is still present, and if it was
rewritten, we reenable it.  While neat and simple, that's not
sufficient, because any calls made in the window after the first call is
resolved, but before it returns, are missed by ltrace.  That could
happen in a multi-threaded program, or when the call itself is recursive
and passes through PLT second time.  If PLTs change on MIPS like that,
then MIPS backend needs to handle this.

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

Passing -L would take care of not meddling with PLT tables.  You could
use -x main to check whether breakpoints work at all.  I.e.:

./ltrace -L -x main a.out # or some such

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

That define really means that there's a custom function
arch_elf_add_plt_entry.  PowerPC in particular has wicked complex PLT
handling, and correspondingly needs special magic for each PLT
breakpoint.

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

This describes what _mangling_ is:
  https://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_C.2B.2B

Demangling is then the opposite process.  Instead of seeing, say,
_ZN9wikipedia7article6formatE, you want to see demangled name,
wikipedia::article::format.

PLT, or Procedure Linkage Table, is a way to bind calls from main binary
to functions in libraries.  For various reasons, instead of doing jumps
from main binary to library, the jump is instead done to a PLT entry,
which then jumps to the corresponding library code.  ltrace uses this
for tracing of library calls.  It puts breakpoints to PLT entries, so
all shared library calls are noticed.  If you are interested in this
plumbing, then I wholeheartedly recommend Ian Taylor's series on
linkers, which starts here:

  http://www.airs.com/blog/archives/38

Mark Wielaard has links for the first several instances.  PLT seems to
be covered in "chapter" 4:

  http://gnu.wildebeest.org/blog/mjw/2007/08/31/ian-lance-taylors-linker-notes/

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

Not that I know of.  You can generally catch me on Freenode as _petr.

Thanks,
PM