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

[Sedat Dilek]

On Tue, Sep 4, 2012 at 12:05 AM, Petr Machata <pmachata at redhat.com> wrote:
> 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.
>

OK.

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

In my latest patchset I kept it.

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

Hm, in GIT master I don't see it being removed.
Forgot 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
>

More to play with :-).
Could you check the ltrace-debug output I sent to you in another email?

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

Yeah, would be great to see you on #ltrace-devel (IRC channel seems
not to exist - so start joining?).

Again, a big ThankYou for all the help, hints and references!

- Sedat -

> Thanks,
> PM