On Tue, Sep 4, 2012 at 3:06 AM, Petr Machata <[email protected]> wrote: > Sedat Dilek <[email protected]> writes: > >> root@fritz:/var/tmp# ./ltrace --config=ltrace.conf --debug=71 ./a.out >> 2>&1 | tee ltrace-debug-71.txt >> >> - Sedat - >> >> P.S.: ltrace-debug-71.txt (XZ-compressed) file attached! > > This looks like setup of _start breakpoint: > > DEBUG: plt.c:41: plt_addr 410830 ndx 0x3 > DEBUG: ltrace-elf.c:511: do_close_elf() > DEBUG: proc.c:748: proc_add_breakpoint(pid=1658, (null)@0x4005a0) > DEBUG: dict.c:158: dict_find_entry() > DEBUG: dict.c:98: dict_enter() > DEBUG: dict.c:124: new dict entry at 0x47ac68[368]: (0x4005a0,0x4570c8) > DEBUG: breakpoint.c:86: enable_breakpoint: pid=1658, addr=0x4005a0, > symbol=(null) > DEBUG: breakpoint.c:49: arch_enable_breakpoint: pid=1658, addr=0x4005a0, > symbol=(null) > DEBUG: proc.c:686: added library a.out@0x400000 (./a.out) to 1658 > > Later it hits: > > DEBUG: events.c:143: next_event() > DEBUG: events.c:200: event from pid 1658 > DEBUG: events.c:334: event: BREAKPOINT: pid=1658, addr=0x4005a0 > DEBUG: handle_event.c:87: handle_event(pid=1658, type=11) > DEBUG: handle_event.c:175: [1658] event: breakpoint 0x4005a0 > DEBUG: handle_event.c:591: handle_breakpoint(pid=1658, addr=0x4005a0) > DEBUG: breakpoints.c:73: address2bpstruct(pid=1658, addr=0x4005a0) > DEBUG: dict.c:158: dict_find_entry() > DEBUG: breakpoints.c:250: delete_breakpoint(pid=1658, addr=0x4005a0) > DEBUG: dict.c:158: dict_find_entry() > DEBUG: breakpoint.c:134: disable_breakpoint: pid=1658, addr=0x4005a0, > symbol=(null) > DEBUG: breakpoint.c:100: arch_disable_breakpoint: pid=1658, addr=0x4005a0, > symbol=(null) > DEBUG: proc.c:770: proc_remove_breakpoint(pid=1658, (null)@0x4005a0) > DEBUG: dict.c:132: dict_remove(0x4005a0) > DEBUG: proc.c:566: linkmap_init() > DEBUG: proc.c:324: find_dynamic_entry() > DEBUG: proc.c:522: load_debug_struct > DEBUG: breakpoints.c:73: address2bpstruct(pid=1658, addr=0x4005a0) > DEBUG: dict.c:158: dict_find_entry() > DEBUG: trace.c:190: continue_process: pid=1658 > > But linkmap_init apparently doesn't populate the library list, otherwise > we would see a flutter of new symbols being enabled all over the place. > It seems like ltrace is misenterpreting the debug struct. That will > need a hands-on work I'm afraid, it's not anything that we can solve by > ping-ponging e-mail messages. >
Don't misunderstand me, I wanted to give you as much informations as I can get. So, as you say for MIPS there is a lot of work. As more like an "enduser" I can't do much than compile, test and give feedback. When I look into the code, this is a quick view. As you renewed many parts, this would take a lot of time for myself. As a summary: MIPS was cleaned-up and compiles again, but does not work properly. Enough good news for me :-). I can understand you have other priorities at work (Red Hat is not supporting MIPS officially)! You know if those other guys worked on ltrace MIPS porting are active? Please, let me know when you start with MIPS work. If you have advices for "small" tasks for me, don't hesitate to ask. I am also around on #ltrace-devel (Freenode) now. Again thanks for your help and analysis. - Sedat - > Thank you, > PM _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
