Eclipse - Error in re-setting breakpoint in C++ Project - c++

I'm using Eclipse Juno with the CDT Plugin, but I've tried in Indigo as well and this problem happens there too. I'm on Ubuntu 12.04.
I've created a new C++ project with the following code. I've set a breakpoint on the second line.
#include <iostream>
using namespace std;
int main() {
cout << "Hello world" << endl;
cout << "Hi there" << endl; // I've set a breakpoint here using eclipse
}
And my Makefile is this
CXX := g++
CXXFLAGS := -g -c
LDFLAGS := -g -std=c++11
OBJ_FILES := main.o
.PHONY: all clean
all: $(OBJ_FILES)
$(CXX) $(LDFLAGS) $(OBJ_FILES) -o proj2
main.o: main.cpp
$(CXX) $(CXXFLAGS) main.cpp -o main.o
clean:
rm -rf *.o proj2
When I run this in Debug mode in eclipse, everything builds fine, but when it runs, gdb spits out this message:
Error in re-setting breakpoint 1: Function "/home/gulshan/Code/EECS281Workspace/Project 2/main.cpp:7" not defined.
It might be worth noting that in this case I've unchecked the option eclipse gives you to break at startup, but when that option is check, it is able to break at the first line without any problem.
What's going on? Here is the GDB trace in case that helps.
707,811 2-environment-cd "/home/gulshan/Code/EECS281Workspace/Project 2"
707,811 2^done
707,812 (gdb)
707,812 3-gdb-set breakpoint pending on
707,813 3^done
707,813 (gdb)
707,814 4-gdb-set detach-on-fork on
707,814 4^done
707,814 (gdb)
707,815 5-enable-pretty-printing
707,815 5^done
707,815 (gdb)
707,815 6-gdb-set python print-stack none
707,816 6^done
707,816 (gdb)
707,816 7-gdb-set print object on
707,817 7^done
707,817 (gdb)
707,818 8-gdb-set print sevenbit-strings on
707,818 8^done
707,818 (gdb)
707,818 9-gdb-set host-charset UTF-8
707,818 9^done
707,819 (gdb)
707,819 10-gdb-set target-charset UTF-8
707,819 10^done
707,819 (gdb)
707,820 11-gdb-set target-wide-charset UTF-32
707,820 11^done
707,820 (gdb)
707,820 12source .gdbinit
707,821 &"source .gdbinit\n"
707,821 &".gdbinit: No such file or directory.\n"
707,821 12^error,msg=".gdbinit: No such file or directory."
707,821 (gdb)
707,822 13-gdb-set target-async off
707,822 13^done
707,822 (gdb)
707,823 14-gdb-set auto-solib-add on
707,823 14^done
707,824 (gdb)
707,827 15-file-exec-and-symbols --thread-group i1 "/home/gulshan/Code/EECS281Workspace/Project 2/pr\
oj2"
707,828 15^done
707,828 (gdb)
707,834 16-break-insert --thread-group i1 -f "\"/home/gulshan/Code/EECS281Workspace/Project 2/main.c\
pp\":7"
707,836 16^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004007d4"\
,func="main()",file="main.cpp",fullname="/home/gulshan/Code/EECS281Workspace/Project 2/main.cpp",lin\
e="7",times="0",original-location="/home/gulshan/Code/EECS281Workspace/Project 2/main.cpp:7"}
707,837 (gdb)
707,843 17-inferior-tty-set --thread-group i1 /dev/pts/2
707,844 17^done
707,844 (gdb)
707,847 18-exec-run --thread-group i1
707,848 =thread-group-started,id="i1",pid="22982"
707,848 =thread-created,id="1",group-id="i1"
707,848 18^running
707,848 *running,thread-id="all"
707,848 (gdb)
707,849 19-list-thread-groups --available
707,851 =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",h\
ost-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
707,870 &"Error in re-setting breakpoint 1: Function \"/home/gulshan/Code/EECS281Workspace/Project 2\
/main.cpp:7\" not defined.\n"
707,872 =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="n",addr="<PENDI\
NG>",pending="/home/gulshan/Code/EECS281Workspace/Project 2/main.cpp:7",times="0",original-location=\
"/home/gulshan/Code/EECS281Workspace/Project 2/main.cpp:7"}
707,873 =library-loaded,id="/usr/lib/x86_64-linux-gnu/libstdc++.so.6",target-name="/usr/lib/x86_64-l\
inux-gnu/libstdc++.so.6",host-name="/usr/lib/x86_64-linux-gnu/libstdc++.so.6",symbols-loaded="0",thr\
ead-group="i1"
707,874 =library-loaded,id="/lib/x86_64-linux-gnu/libc.so.6",target-name="/lib/x86_64-linux-gnu/libc\
.so.6",host-name="/lib/x86_64-linux-gnu/libc.so.6",symbols-loaded="0",thread-group="i1"
707,874 =library-loaded,id="/lib/x86_64-linux-gnu/libm.so.6",target-name="/lib/x86_64-linux-gnu/libm\
.so.6",host-name="/lib/x86_64-linux-gnu/libm.so.6",symbols-loaded="0",thread-group="i1"
707,874 =library-loaded,id="/lib/x86_64-linux-gnu/libgcc_s.so.1",target-name="/lib/x86_64-linux-gnu/\
libgcc_s.so.1",host-name="/lib/x86_64-linux-gnu/libgcc_s.so.1",symbols-loaded="0",thread-group="i1"
708,269 =thread-exited,id="1",group-id="i1"
708,270 =thread-group-exited,id="i1",exit-code="0"
708,270 *stopped,reason="exited-normally"
708,270 (gdb)
708,278 20-gdb-exit
708,278 21-data-evaluate-expression $_exitcode
708,291 19^error,msg="Quit"
708,291 (gdb)
708,292 20^exit
708,292 22-break-delete --thread-group i1 1

Looks like there's a bug in GDB 7.4 that has a problem with setting breakpoints using paths with spaces: http://sourceware.org/bugzilla/show_bug.cgi?id=13798
I've removed all of the spaces in the path containing the file and it works now.

It may happen also if you have modified the code during a debug session. Just Run/"Remove all breakpoints" solves the problem.

Related

How do I solve make: None: Command not found issue?

I am having trouble understanding this error.
make: None: Command not found
make: *** [Makefile:3879: api/api_commands.o] Error 127
I have tried looking but I can't find an answer to the specific issue make: None:.
The full issue and error message is here for clarification.
Help on this would be highly appreciated.
Update
The make file consists of the following (line 3879 separated from the rest for clarification):
...
includes_65 = -I../src/tactic/portfolio -I../src/tactic/smtlogics -I../src/ackermannization -I../src/model -I../src/ast/rewriter -I../src/ast -I../src/util -I../src/math/polynomial -I../src/math/automata -I../src/solver -I../src/tactic -I../src/ast/proofs -I../src/sat/sat_solver -I../src/tactic/core -I../src/ast/macros -I../src/ast/normal_forms -I../src/tactic/aig -I../src/tactic/bv -I../src/ast/rewriter/bit_blaster -I../src/tactic/arith -I../src/sat -I../src/sat/tactic -I../src/nlsat/tactic -I../src/nlsat -I../src/smt/tactic -I../src/smt -I../src/cmd_context -I../src/interp -I../src/smt/proto_model -I../src/smt/params -I../src/ast/pattern -I../src/parsers/smt2 -I../src/parsers/util -I../src/ast/substitution -I../src/math/grobner -I../src/math/euclid -I../src/math/simplex -I../src/ast/fpa -I../src/util/lp -I../src/muz/fp -I../src/muz/base -I../src/qe -I../src/muz/pdr -I../src/muz/transforms -I../src/math/hilbert -I../src/muz/dataflow -I../src/muz/clp -I../src/muz/tab -I../src/muz/rel -I../src/muz/bmc -I../src/muz/duality -I../src/duality -I../src/muz/ddnf -I../src/muz/spacer -I../src/tactic/nlsat_smt -I../src/tactic/ufbv -I../src/tactic/fpa -I../src/tactic/sls -I../src/math/subpaving/tactic -I../src/math/subpaving -I../src/math/interval -I../src/math/realclosure -I../src/opt -I../src
api/z3_macros.h.node: ../src/api/z3_macros.h
#echo done > api/z3_macros.h.node
api/z3_api.h.node: ../src/api/z3_api.h
#echo done > api/z3_api.h.node
...
api/api_ast_vector$(OBJ_EXT): ../src/api/api_ast_vector.cpp api/z3.h.node api/api_log_macros.h.node api/api_context.h.node api/api_ast_vector.h.node ast/ast_translation.h.node ast/ast_smt2_pp.h.node
#echo src/api/api_ast_vector.cpp
#$(CXX) $(CXXFLAGS) $(includes_65) $(CXX_OUT_FLAG)api/api_ast_vector$(OBJ_EXT) ../src/api/api_ast_vector.cpp
api/api_bv$(OBJ_EXT): ../src/api/api_bv.cpp api/z3.h.node api/api_log_macros.h.node api/api_context.h.node api/api_util.h.node ast/bv_decl_plugin.h.node
#echo src/api/api_bv.cpp
#$(CXX) $(CXXFLAGS) $(includes_65) $(CXX_OUT_FLAG)api/api_bv$(OBJ_EXT) ../src/api/api_bv.cpp
api/z3_replayer.h.node: ../src/api/z3_replayer.h api/z3.h.node util/z3_exception.h.node
#echo done > api/z3_replayer.h.node
api/api_commands$(OBJ_EXT): ../src/api/api_commands.cpp api/z3.h.node api/z3_replayer.h.node
#echo src/api/api_commands.cpp
#$(CXX) $(CXXFLAGS) $(includes_65) $(CXX_OUT_FLAG)api/api_commands$(OBJ_EXT) ../src/api/api_commands.cpp
api/api_config_params$(OBJ_EXT): ../src/api/api_config_params.cpp api/z3.h.node
...
Since the previous lines in the make file are of similar format and did not cause any errors, the problem must lie within the api_commands.cpp file. I have looked into this file, but I can't understand what is happening in this code exactly, so I cannot interpret where a None variable is created.
The api_commands.cpp file in question is 4856 lines long, but it consists of several functions of ther format
void exec_Z3_params_set_bool(z3_replayer & in) {
Z3_params_set_bool(
reinterpret_cast<Z3_context>(in.get_obj(0)),
reinterpret_cast<Z3_params>(in.get_obj(1)),
in.get_symbol(2),
in.get_bool(3));
}
and a function void register_z3_replayer_cmds(z3_replayer & in) containing lines such as
in.register_cmd(16, exec_Z3_params_set_bool, "Z3_params_set_bool");
If anyone is familiar with such or similar code and would know how this file is creating a None variable, your help would be highly appreciated.

Linker error: ELF section name out of range

What does this "ELF section name out of range" error mean?
I am trying to build a binary, but constantly getting this linker error.
root#ubuntu:/home/ubuntu/e2c/e2c_core# make all
arm-oe-linux-gnueabi-g++ --sysroot=/home/ubuntu/sysroots/aarch64-oe-linux/ -O0 -g -Wall -fmessage-length=0 -MD -MP -DLINUX=1 -DUSE_CONFIG_FILE=1 --sysroot=/home/ubuntu/sysroots/aarch64-oe-linux/ -fstack-protector -fPIE -z relro -z now -D_FORTIFY_SOURCE=2 -std=c++0x -O3 -Wall -fmessage-length=0 -MD -MP -DLINUX=1 -DUSE_CONFIG_FILE=1 -D__MOCANA_DISABLE_INLINE_ASSEMBLY__ -I. -Iapi/ -Icfg/ -Iplatform/ -Icore/ -Icore/Diagnostics/ -Icore/GreyhoundThread/ -Icore/LIB_Mocana/ -Icore/LIB_ProtonE/ -Icore/Mocana/ -Icore/PKI/ -Icore/Telemetry/ -Icore/UTCtimeSync/ -Icore/jsmn/ -I../e2c_api/ -Ilib/atecclib/ -Ilib/atecclib/lib/ -Ilib/config/ -I../boost/ -I/home/ubuntu/Downloads/libwebsockets/build/include/ -Icore/LIB_Mocana/src/ocsp/ -Iunity/ -include core/E2C_global_include.h -o e2c_core main.o api/api_diy.o api/api_rci.o api/api_sta.o api/TelemetryInterface.o cfg/CloudVariantSetup.o cfg/SwVersion.o core/e2c_core_config.o core/E2C_internal_main.o core/Diagnostics/LegacyDBdiag.o core/GreyhoundThread/FirmwareDownload.o core/GreyhoundThread/GreyhoundThread.o core/GreyhoundThread/Provisioning.o core/GreyhoundThread/UTCtimeSync.o core/GreyhoundThread/WS_Provisioning.o core/jsmn/jsmn.o core/LIB_Mocana/src/asn1/ASN1TreeWalker.o core/LIB_Mocana/src/asn1/derencoder.o core/LIB_Mocana/src/asn1/oiddefs.o core/LIB_Mocana/src/asn1/oidutils.o core/LIB_Mocana/src/asn1/parseasn1.o core/LIB_Mocana/src/asn1/parsecert.o core/LIB_Mocana/src/common/absstream.o core/LIB_Mocana/src/common/altivec.o core/LIB_Mocana/src/common/circ_buf.o core/LIB_Mocana/src/common/circq.o core/LIB_Mocana/src/common/datetime.o core/LIB_Mocana/src/common/debug_console.o core/LIB_Mocana/src/common/dynarray.o core/LIB_Mocana/src/common/hash_table.o core/LIB_Mocana/src/common/hash_value.o core/LIB_Mocana/src/common/int128.o core/LIB_Mocana/src/common/int64.o core/LIB_Mocana/src/common/jacobi.o core/LIB_Mocana/src/common/lucas.o core/LIB_Mocana/src/common/math_arm.o core/LIB_Mocana/src/common/mbitmap.o core/LIB_Mocana/src/common/memfile.o core/LIB_Mocana/src/common/memory_debug.o core/LIB_Mocana/src/common/mem_part.o core/LIB_Mocana/src/common/mem_pool.o core/LIB_Mocana/src/common/merrors.o core/LIB_Mocana/src/common/mocana.o core/LIB_Mocana/src/common/moc_net.o core/LIB_Mocana/src/common/moc_stream.o core/LIB_Mocana/src/common/mprintf.o core/LIB_Mocana/src/common/mrtos.o core/LIB_Mocana/src/common/mstdlib.o core/LIB_Mocana/src/common/mtcp.o core/LIB_Mocana/src/common/prime.o core/LIB_Mocana/src/common/random.o core/LIB_Mocana/src/common/redblack.o core/LIB_Mocana/src/common/rng_seed.o core/LIB_Mocana/src/common/sizedbuffer.o core/LIB_Mocana/src/common/timer.o core/LIB_Mocana/src/common/tree.o core/LIB_Mocana/src/common/uri.o core/LIB_Mocana/src/common/utils.o core/LIB_Mocana/src/common/vlong.o core/LIB_Mocana/src/crypto/aesalgo.o core/LIB_Mocana/src/crypto/aesalgoNi.o core/LIB_Mocana/src/crypto/aes_ccm.o core/LIB_Mocana/src/crypto/aes_cmac.o core/LIB_Mocana/src/crypto/aes.o core/LIB_Mocana/src/crypto/aes_ctr.o core/LIB_Mocana/src/crypto/aes_eax.o core/LIB_Mocana/src/crypto/aes_ecb.o core/LIB_Mocana/src/crypto/aes_keywrap.o core/LIB_Mocana/src/crypto/aes_xcbc_mac_96.o core/LIB_Mocana/src/crypto/aes_xts.o core/LIB_Mocana/src/crypto/ansix9_63_kdf.o core/LIB_Mocana/src/crypto/arc2.o core/LIB_Mocana/src/crypto/arc4.o core/LIB_Mocana/src/crypto/asn1cert.o core/LIB_Mocana/src/crypto/base64m.o core/LIB_Mocana/src/crypto/blowfish.o core/LIB_Mocana/src/crypto/ca_mgmt.o core/LIB_Mocana/src/crypto/cert_store.o core/LIB_Mocana/src/crypto/cms_aux.o core/LIB_Mocana/src/crypto/crypto.o core/LIB_Mocana/src/crypto/des.o core/LIB_Mocana/src/crypto/dh.o core/LIB_Mocana/src/crypto/dsa2.o core/LIB_Mocana/src/crypto/dsa.o core/LIB_Mocana/src/crypto/fips.o core/LIB_Mocana/src/crypto/gcm.o core/LIB_Mocana/src/crypto/hmac.o core/LIB_Mocana/src/crypto/key_utils.o core/LIB_Mocana/src/crypto/md2.o core/LIB_Mocana/src/crypto/md45.o core/LIB_Mocana/src/crypto/md4.o core/LIB_Mocana/src/crypto/md5.o core/LIB_Mocana/src/crypto/nil.o core/LIB_Mocana/src/crypto/nist_rng.o core/LIB_Mocana/src/crypto/pem_key.o core/LIB_Mocana/src/crypto/pkcs10.o core/LIB_Mocana/src/crypto/pkcs12.o core/LIB_Mocana/src/crypto/pkcs1.o core/LIB_Mocana/src/crypto/pkcs5.o core/LIB_Mocana/src/crypto/pkcs7.o core/LIB_Mocana/src/crypto/pkcs8.o core/LIB_Mocana/src/crypto/pkcs_common.o core/LIB_Mocana/src/crypto/pkcs.o core/LIB_Mocana/src/crypto/pkcs_key.o core/LIB_Mocana/src/crypto/primeec_atecc.o core/LIB_Mocana/src/crypto/primeec.o core/LIB_Mocana/src/crypto/primefld.o core/LIB_Mocana/src/crypto/pubcrypto.o core/LIB_Mocana/src/crypto/rc2algo.o core/LIB_Mocana/src/crypto/rc4algo.o core/LIB_Mocana/src/crypto/rsa.o core/LIB_Mocana/src/crypto/sec_key.o core/LIB_Mocana/src/crypto/sha1.o core/LIB_Mocana/src/crypto/sha256.o core/LIB_Mocana/src/crypto/sha512.o core/LIB_Mocana/src/crypto/three_des.o core/LIB_Mocana/src/ocsp/client/ocsp_client.o core/LIB_Mocana/src/ocsp/ocsp_context.o core/LIB_Mocana/src/ocsp/ocsp.o core/LIB_Mocana/src/ocsp/ocsp_http.o core/LIB_Mocana/src/ocsp/ocsp_message.o core/LIB_Mocana/src/platform/linux_rtos.o core/LIB_Mocana/src/platform/linux_tcp_async.o core/LIB_Mocana/src/platform/linux_tcp.o core/LIB_Mocana/src/platform/linux_udp.o core/LIB_Mocana/src/ssl/ssl.o core/LIB_Mocana/src/ssl/ssl_ocsp.o core/LIB_Mocana/src/ssl/sslsock.o core/LIB_ProtonE/src/buffer.o core/LIB_ProtonE/src/error.o core/LIB_ProtonE/src/log.o core/LIB_ProtonE/src/parser.o core/LIB_ProtonE/src/pn_platform.o core/LIB_ProtonE/src/scanner.o core/LIB_ProtonE/src/selectable.o core/LIB_ProtonE/src/types.o core/LIB_ProtonE/src/url.o core/LIB_ProtonE/src/util.o core/LIB_ProtonE/src/codec/codec.o core/LIB_ProtonE/src/codec/decoder.o core/LIB_ProtonE/src/codec/encoder.o core/LIB_ProtonE/src/dispatcher/dispatcher.o core/LIB_ProtonE/src/engine/engine.o core/LIB_ProtonE/src/events/event.o core/LIB_ProtonE/src/framing/framing.o core/LIB_ProtonE/src/message/message.o core/LIB_ProtonE/src/messenger/messenger.o core/LIB_ProtonE/src/messenger/store.o core/LIB_ProtonE/src/messenger/subscription.o core/LIB_ProtonE/src/messenger/transform.o core/LIB_ProtonE/src/object/iterator.o core/LIB_ProtonE/src/object/list.o core/LIB_ProtonE/src/object/map.o core/LIB_ProtonE/src/object/object.o core/LIB_ProtonE/src/object/record.o core/LIB_ProtonE/src/object/string.o core/LIB_ProtonE/src/posix/io.o core/LIB_ProtonE/src/posix/selector.o core/LIB_ProtonE/src/sasl/none_sasl.o core/LIB_ProtonE/src/sasl/sasl.o core/LIB_ProtonE/src/ssl/mocanassl_proton.o core/LIB_ProtonE/src/transport/autodetect.o core/LIB_ProtonE/src/transport/transport.o core/Mocana/MocSetup.o core/Mocana/MocTest.o core/Mocana/TLS_http_get.o core/PKI/CertificateStore.o core/PKI/ILVT.o core/PKI/MDKcode.o core/Telemetry/AMQPlayer.o core/Telemetry/GatewayTerminatedMessages.o core/Telemetry/GHbase64.o core/Telemetry/GHsequence.o core/Telemetry/MsgRouting.o core/Telemetry/RegistrationFlag.o core/Telemetry/TelemetryThread.o core/Telemetry/WSlayer.o core/Telemetry/WS_Stats.o core/Telemetry/PELIB/PELIBassert.o core/Telemetry/PELIB/PELIBmemoryMgmt.o core/Telemetry/PELIB/PELIBplatform.o core/UTCtimeSync/UTCtime.o core/UTCtimeSync/UTCtimeSyncJSON.o platform/Daemon.o platform/Linux_api.o platform/Logger.o platform/Platform.o platform/STA_DNScache.o platform/e2c/BL-RO-Store.o platform/e2c/ConfigStore.o platform/e2c/DebugPrint.o platform/e2c/DeviceConfig.o platform/e2c/E2C_FILE.o platform/e2c/MemoryManager.o platform/e2c/PlatformFileSystem.o lib/config/grammar.o lib/config/libconfig.o lib/config/scanctx.o lib/config/scanner.o lib/config/strbuf.o lib/config/libconfigcpp.o lib/atecclib/libatecc508.a -L../e2c_api/ -L/home/ubuntu/Downloads/libwebsockets/build/lib/ -Wl,--whole-archive -lpthread -ldl -Wl,--no-whole-archive -le2c_api -lrt -lwebsockets -luuid -lcurl
/home/ubuntu/sysroots/x86_64-oesdk-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.9.3/real-ld: fatal error: /home/ubuntu/sysroots/aarch64-oe-linux/usr/lib/libstdc++.so: ELF section name out of range
What does this actually mean?
In my case I was getting ld : error : myfile: file too short, or sometimes:
ld: warning: myfile has a section extending past end of file
ld : error : myfile: ELF section name out of range
because I was patching for Nix a folder containing both source code and binary blob… and since the number of files to patch was high I used a script to patch them all at the same time (using find and sed -i). Unfortunately, sed was also applied on binary files, which completely corrupted them.
I realized that by printing objdump -a myfile before and after the patching (I would get an error in the second case).

How to identify the full command that caused the crash from the core dump file

There is a problem to identify the full command from the core dump file using gdb
The crashed command itself can be long
i.e.
myCommand -f log/SlaRunTimeReport.rep -I input/myFile.txt -t output/myFile.txt
But When using gdb to identify the command in the location “Core was generated by”
i.e. by executing
gdb -c core.56536
The Output:
GNU gdb (GDB) Red Hat Enterprise Linux 7.10-20.el7
….
Core was generated by `myCommand -f log/SlaRunTimeReport.rep -I
input/myFile.t'.
It is possible to see that the full command(executable + parameters) was cut in the middle
‘myCommand -f log/SlaRunTimeReport.rep -I input/myFile.t'
In additional using strings command , also did not help to identify the full command
strings core.56536 | grep PMRunTimeReport
The Output:
myCommand
myCommand -f log/SlaRunTimeReport.rep -I input/myFile.t
Is there any way to get from coredump file the full command that caused the failure
Thanks in Advance
Is there any way to get from coredump file the full command that caused the failure
There are multiple ways, but running strings is the wrong way.
IF you built your program with debug info, you should be able to simply execute up command until you reach main, then examine argv[0] through argv[argc-1].
If your main was not built with debug info, or if it doesn't use argc and argv, you should be able to recover that info from __libc_argc and __libc_argv variables. Example:
$ ./a.out foo bar baz $(python -c 'print "a" * 500')
Aborted (core dumped)
$ gdb -q ./a.out core
Core was generated by `./a.out foo bar baz aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'.
Note that the "generated by" is truncated -- it comes from a fixed length array inside of struct prpsinfo, saved in NT_PRPSINFO ELF note in the core.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007fab38cfcf2b in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.27-15.fc28.x86_64
(gdb) p (int)__libc_argc
$1 = 5
(gdb) p ((char**)__libc_argv)[0]#5
$2 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
0x7ffede4328af "baz",
0x7ffede4328b3 'a' <repeats 200 times>...}
This last line is actually a lie -- we know that 'a' repeats 500 times.
We can fix it like so:
(gdb) set print elem 0
(gdb) p ((char**)__libc_argv)[0]#5
$3 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
0x7ffede4328af "baz",
0x7ffede4328b3 'a' <repeats 500 times>}
Voila: we now have the complete command.
Lastly, if you install debug info for GLIBC, you can simply look in the __libc_start_main (which called your main):
(gdb) set backtrace past-main
(gdb) bt
#0 __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fab38ce7561 in __GI_abort () at abort.c:79
#2 0x00000000004004ef in main () at foo.c:3
#3 0x00007fab38ce918b in __libc_start_main (main=0x4004e6 <main>, argc=5, argv=0x7ffede431118,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffede431108)
at ../csu/libc-start.c:308
#4 0x000000000040042a in _start ()
Here you can clearly see argc and argv in frame 3, and can examine that argv like so:
(gdb) fr 3
#3 0x00007fab38ce918b in __libc_start_main (main=0x4004e6 <main>, argc=5, argv=0x7ffede431118,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffede431108)
at ../csu/libc-start.c:308
308 result = main (argc, argv, __environ MAIN_AUXVEC_PARAM);
(gdb) p argv[0]#5
$1 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
0x7ffede4328af "baz",
0x7ffede4328b3 'a' <repeats 500 times>}

llvm::DIInstruction getFilename returns filename with a directory, I just want the filename

I'm trying to get debugging metadata from an llvm Instruction using the DILocation class.
However, when I query the DILocation for the filename where the instruction came from, I get a filename with a
directory tagged onto the front.
I though it would return just the file
and the entire directory path should be retrieved via a call to getDirectory().
For example, instead of XMain_0.c I end up with pbg/XMain_0.c
I compiled my bitcode like this:
XMain_0.o: pbg/XMain_0.c
$(CC) <snip> -c pbg/XMain_0.c
Does the fact that I passed in my source with a directory on it
mean that the metadata saves the source filename as the input?
Here's a cut down example:
const llvm::Instruction* inst //passed in
MDNode *n = inst->getMetadata("dbg");
DILocation loc(n);
file = loc.getFilename().str(); // => pbg/XMain_0.c
dir = loc.getDirectory().str(); // => /projects/pbg/pbg-m/DIR
Are there calls I can make to "normalize" this data or do I need to do it by hand?
Clang 3.1 if that matters.
I think it depends on the invocation of the compiler. If you run:
clang -c somedir/somefile.c
Then the full somedir/somefile.c will be the filename.
How does your invocation look like?
There is nothing weird about it. The debugger will look for source files relative to some project root, and if you compile files likes this, it's the way they are going to be found. gcc does the same thing:
/tmp$ pwd
/tmp
/tmp$ cat subdir/test.c
int foo() {
return 42;
}
/tmp$ gcc -g -O0 -c subdir/test.c -o test.o
/tmp$ readelf --debug-dump=info test.o | grep -A4 compile_unit
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x0): GNU C 4.6.3
<10> DW_AT_language : 1 (ANSI C)
<11> DW_AT_name : (indirect string, offset: 0xc): subdir/test.c
<15> DW_AT_comp_dir : (indirect string, offset: 0x1a): /tmp

How to log all commands run By system() System Call

I am trying to debug a C++ application which invokes many command line applications such as grep, etc through a the system() system call. I need to see all the commands the application is executing through the system() call.
I tried to view these commands by enabling history and view the .history file. But these commands are not executed through a terminal. The history file has only the commands executed interactively.
Any idea how this can be done?
Define a new macro with similar name:
#define system(_x) std::cout << _x << std::endl; (system)(_x);
The system macro replaces the system function and:
It prints the command to the standard output (or elsewhere).
It calls the system function.
Thanks to Hasturkun's suggestion, the following is better:
#define system(_x) (std::cout << (_x) << std::endl, system(_x))
That returns the result of system function call, too ;-)
To trace every command executed by "yourProgram":
truss -s!all -daDf -t exec yourProgram
eg:
$ truss -s!all -daDf -t exec sh -c "/bin/echo hello world;/bin/date"
Base time stamp: 1282164973.7245 [ Wed Aug 18 22:56:13 CEST 2010 ]
5664: 0.0000 0.0000 execve("/usr/bin/i86/ksh93", 0x080471DC, 0x080471EC) argc = 3
5664: argv: sh -c /bin/echo hello world;/bin/date
5665: 0.0106 0.0106 execve("/bin/echo", 0x08067484, 0x080674F8) argc = 3
5665: argv: /bin/echo hello world
hello world
5664: 0.0126 0.0126 execve("/bin/date", 0x080674E0, 0x080674F8) argc = 1
5664: argv: /bin/date
Wed Aug 18 22:56:13 CEST 2010
If you want to correlate these execs to system() calls, you can use that command:
truss -t execve -f -u 'libc:system' yourProgram
eg:
$ cat a.c
main()
{
system("echo a b c");
system("pwd");
}
$ truss -t execve -f -u 'libc:system' ./a
20073: execve("a", 0x08047240, 0x08047248) argc = 1
20073/1#1: -> libc:system(0x8050a5c, 0x0)
20074/1: execve("/bin/sh", 0x080471BC, 0x08047248) argc = 3
a b c
20073/1#1: <- libc:system() = 0
20073/1#1: -> libc:system(0x8050a68, 0x0)
20076/1: execve("/bin/sh", 0x080471BC, 0x08047248) argc = 3
/tmp
20073/1#1: <- libc:system() = 0
Finally, if you are using Solaris 10 or newer, you can use Dtrace for this task like this:
dtrace -Z -q -c yourProgram -n ' pid$target:libc:system:entry { printf("system(\"%s\")\n", copyinstr(arg0)); } '
which will give that output with the same "a" code:
a b c
/tmp
system("echo a b c")
system("pwd")
PS: By the way system() isn't a system call but a standard library function.
You can use truss or strace (Not sure which one comes with Solaris) to run the program and trace the calls to system.
For truss the relevant command will be something like truss -caf program_name