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

[Sedat Dilek]

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

[ Addendum #2 ]

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

Output attached!

- Sedat -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltrace-L-S-x-main-debug-71.txt.xz
Type: application/octet-stream
Size: 5040 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20120904/ebc9e27e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltrace-debug-71.txt.xz.sha256sum
Type: application/octet-stream
Size: 88 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20120904/ebc9e27e/attachment-0001.obj>