Re: Debugging problems

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Wed Sep 09 2009 - 10:16:51 PDT

  • Next message: Paul H. Hargrove: "Re: Debugging problems"
    Nikita,
    
    I believe the problems you are encountering come from the fact that -g 
    and -inst are currently mutually exclusive (you get one or you get the 
    other).
    
    Your "this copy of Berkeley UPC was not built with GASP instrumentation 
    support" problem is this first sign of this conflict, thought the error 
    message is misleading.  A build of Berkeley UPC actually consists of 
    multiple sub-builds configured with different options to build the 
    different versions of the runtime library (you have noticed the "opt", 
    "dbg" and "opt_inst" subdirectories in both the build and install 
    directory).  The upcc script uses the flags -O, -g and -inst to choose 
    which build to use for the given compilation request.  Since we match on 
    the '-g' before the '-inst' we compile with a build that has debugging 
    configured in, but does not have the GASP instrumentation support.  The 
    error message you see is because the debug sub-build selected by the -g 
    option doesn't have GASP support.
    
    When you invoke opt_inst/bin/upcc you got the GASP support you wanted, 
    but then the -g you pass is either going to affect only your objects or 
    none at all (not sure off the top of my head).  What I am certain about 
    is that the -g is not going to link your program with runtime libraries 
    that contain any debug information (such as line numbers).
    
    I believe there is a way to force creation of an additional sub-build 
    with what you want, but not by default.  I am going to look into it and 
    will follow up with a second e-mail containing details of what I find.
    
    -Paul
    
    Andreev Nikita wrote:
    > Hello, guys
    >
    > I've ran into a problem while debugging UPC application with GASP
    > support.
    >
    > I've read an article concerning debugging UPC applications with GDB at
    > http://upc.lbl.gov/docs/user/upc-debugging.html. I tried to compile
    > gasp_test.upc program (from distrib) by issuing
    > "/opt/bupc-runtime-gasp-2.8.0/bin/upcc -network=udp -g gasp_test.upc"
    > and run by "UPC_NODES=127.0.0.1
    > /opt/bupc-runtime-gasp-2.8.0/bin/upcrun -freeze=0 -n 1 a.out". Then I
    > attached GDB and all worked fine.
    >
    > When I tried to compile with gasp tracing tool:
    > "/opt/bupc-runtime-gasp-2.8.0/bin/upcc -g -network=udp
    > -inst-toolname=trace-mod -L/root/trace-mod/lib -ltracer --inst-func
    > /root/trace-mod/src/aux.c gasp_test.c"
    >
    > compiler said "upcc: Error: -inst: this copy of Berkeley UPC was not
    > built with GASP instrumentation support - reconfigure with
    > --enable-inst" event though UPC runtime WAS compiled with GASP
    > support (if I compile without "-g" GASP tracing works fine). Because
    > of this error I had to change upcc path to
    > "/opt/bupc-runtime-gasp-2.8.0/opt_inst/bin/upcc" (I don't really know
    > what I've done) and "-g" seems started working. But not really. When I
    > attach GDB to the proccess and try debug something it always says
    > "Single stepping until exit from function gaspu_dump_shared, which has
    > no line number information." and I can't find out what was the cause
    > of program crash. Here is the log:
    >
    > # gdb a.out 13618
    > GNU gdb Fedora (6.8-27.el5)
    > Copyright (C) 2008 Free Software Foundation, Inc.
    > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    > This is free software: you are free to change and redistribute it.
    > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    > and "show warranty" for details.
    > This GDB was configured as "x86_64-redhat-linux-gnu"...
    > Attaching to program: /root/trace-mod/upc/a.out, process 13618
    > Reading symbols from /usr/lib64/libstdc++.so.6...done.
    > Loaded symbols for /usr/lib64/libstdc++.so.6
    > Reading symbols from /lib64/libm.so.6...done.
    > Loaded symbols for /lib64/libm.so.6
    > Reading symbols from /lib64/libgcc_s.so.1...done.
    > Loaded symbols for /lib64/libgcc_s.so.1
    > Reading symbols from /lib64/libc.so.6...done.
    > Loaded symbols for /lib64/libc.so.6
    > Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
    > Loaded symbols for /lib64/ld-linux-x86-64.so.2
    > Reading symbols from /lib64/libnss_files.so.2...done.
    > Loaded symbols for /lib64/libnss_files.so.2
    > 0x00000030208b9d47 in sched_yield () from /lib64/libc.so.6
    > (gdb) b gaspu_dump_shared
    > Breakpoint 1 at 0x403190
    > (gdb) set bupc_frozen=0
    > (gdb) c
    > Continuing.
    >
    > Breakpoint 1, 0x0000000000403190 in gaspu_dump_shared ()
    > (gdb) s
    > Single stepping until exit from function gaspu_dump_shared, 
    > which has no line number information.
    > fill_MEMPUT (c_rec=0x111a5a10, varargs=0x7fff3952bbf0) at ./src/tracer.c:404
    > ...
    >
    > I tried to add "-save-temps" but it doesn't change anything. Maybe I
    > don't quite grasp something but upcc don't want to add debugging
    > information to UPC application when I compile with GASP tracing tool
    > (--inst and other flags).
    >
    > Give me a clue.
    >
    > Thank you,
    > Nikita.
    >
    >
    >
    >
    >   
    
    
    -- 
    Paul H. Hargrove                          PHHargrove_at_lbl_dot_gov
    Future Technologies Group                 Tel: +1-510-495-2352
    HPC Research Department                   Fax: +1-510-486-6900
    Lawrence Berkeley National Laboratory     
    

  • Next message: Paul H. Hargrove: "Re: Debugging problems"