On Tue, Sep 4, 2012 at 1:22 AM, Sedat Dilek <[email protected]> wrote: > On Tue, Sep 4, 2012 at 12:25 AM, Sedat Dilek <[email protected]> wrote: >> On Tue, Sep 4, 2012 at 12:05 AM, Petr Machata <[email protected]> wrote: >>> Sedat Dilek <[email protected]> writes: >>> >>>> On Mon, Sep 3, 2012 at 12:29 PM, Petr Machata <[email protected]> wrote: >>>>> Sedat Dilek <[email protected]> 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@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@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 -
ltrace-L-S-x-main-debug-71.txt.xz
Description: Binary data
ltrace-debug-71.txt.xz.sha256sum
Description: Binary data
_______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
