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

[Sedat Dilek]

On Tue, Sep 4, 2012 at 12:25 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> 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

[ Addendum ]

root at fritz:/var/tmp# ./ltrace --config=./ltrace.conf -L -x main
./a.out 2>&1 | tee ltrace-L-x-main.txt

Output attached!

- Sedat -
-------------- next part --------------
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0 <unfinished ...>
main(1, 0x7fe3c9f4, 0x7fe3c9fc, 0callstack_push_symfunc: Error: call nesting too deep!