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 -
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!
_______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
