I have bunch of source code which I compiled using -ggdb3 flag.
I have copied the source code and executable to an another machine.
When I run the exe in gdb it does not show the statements at the line numbers when it breaks.
This is what I see
Breakpoint 1, TestCode (handler=0x806e110, args=0xffffd2b0)
at ../myfile.c:1080
1080 ../myfile.c: No such file or directory.
(gdb) n
1083 in ../myfile.c
(gdb)
1084 in ../myfile.c
(gdb)
1085 in ../myfile.c
I even tried setting the dir path using gdb dir command by giving the name of the topmost directory of the source code but no help.
Example my source code directory structure is like
C
|
--------------
| |
D E
|
F
|
-----------
| |
S T
The file I am debugging may be in some inner folder say F.
While I gave the path of folder C in gdb dir
dir /home/C
Any way to resolve this issue?
More details are:
> OS SUSE Linux Enterprise Server 11 (x86_64)
> gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux)
> GNU gdb (GDB) SUSE (7.5.1-0.7.29)
Here are the Makefile details
#
# Makefile for building demo code on SUSE Linux
all : SLIBINSTALLDIR = $(SDESTDIR)$(SLIBDIR)
###########################################
# Defines #
###########################################
CC = --mode=compile gcc
LINK =$(DESTDIR)libtool --mode=link gcc
INDEPSDIR = ../../../../../dependencies/internal
MODULE = TestCode
INCLUDE = -I../ -I$(INDEPSDIR)/include
CFLAGS := $(CFLAGS) $(INCLUDE) -DN_PLAT_UNIX -DN_PLAT_GNU -DVERSION=0x00010002 -D_GNU_SOURCE -g -ggdb3
CSRC = ../myfile.c ../decode.c ../encode.c
COBJ = $(CSRC:.c=.o)
COBJ1 = $(CSRC:.c=.lo)
TestCode:$(COBJ)
$(LINK) $(CFLAGS) -o TestCode $(COBJ1) -all-static
DESRC = ../main.c
DEOBJ = $(DESRC:.c=.o)
You should define a source path substitution rule using command:
set substitute-path from to
It will substitute from part into to allowing to find sources in new location.
See https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html.
Also info sources command will be useful to remember from part in the command above in case you forgot where your sources were located before copying.
Related
I want to debug with stander library in gdb.
I ran gdb with argument -d to specify the source file of standard libary.
$ gdb ./test -d /usr/src/glibc/glibc-2.27/
test.cpp:
#include<iostream>
#include<string>
using namespace std;
int main(){
string hex("0x0010");
long hex_number = strtol(hex.c_str(), NULL, 16);
cout << hex_number << endl;
return 0;
}
However, gdb told me it can not find source file strtol.c.
(gdb) b 8
Breakpoint 1 at 0xc8c: file /home/purin/Desktop/CodeWork/adv_unix_programming/hw1/test.cpp, line 8.
(gdb) run
Starting program: /home/purin/Desktop/CodeWork/adv_unix_programming/hw1/test
Breakpoint 1, main () at /home/purin/Desktop/CodeWork/adv_unix_programming/hw1/test.cpp:8
8 long hex_number = strtol(hex.c_str(), NULL, 16);
(gdb) s
__strtol (nptr=0x7fffffffd820 "0x0010", endptr=0x0, base=16) at ../stdlib/strtol.c:106
106 ../stdlib/strtol.c: file or directory does not exits
(gdb) info source
Current source file is ../stdlib/strtol.c
Compilation directory is /build/glibc-OTsEL5/glibc-2.27/stdlib
Source language is c.
Producer is GNU C11 7.3.0 -mtune=generic -march=x86-64 -g -O2 -O3 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math -fstack-protector-strong -fPIC -ftls-model=initial-exec -fstack-protector-strong.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
Since gdb can find source code if I execute this command:
(gdb) dir /usr/src/glibc/glibc-2.27/stdlib/
I am sure that I have strtol.c in path /usr/src/glibc/glibc-2.27/stdlib/strtol.c and the library has debug information.
Why gdb cannot search the directories under /usr/src/glibc/glibc-2.27/ to find out stdlib/strtol.c?
Maybe the reason is that if you join two paths /usr/src/glibc/glibc-2.27/ and ../stdlib/strtol.c you get the path /usr/src/glibc/stdlib/strtol.c, but not the expected path /usr/src/glibc/glibc-2.27/stdlib/strtol.c. The reason why ../stdlib/strtol.c is stored in the debug info, very likely is a build directory /build/glibc-OTsEL5/glibc-2.27/build used, and ../stdlib/strtol.c is the relative path to the build directory.
One of solutions is run
$ gdb ./test -d /usr/src/glibc/glibc-2.27/stdlib/
I want to use ArduinoCore-avr in my project. I don't want to use arduino's IDE default function setup() and loop(). I also don't want to use arduino's IDE to compile and burn hex file into my device. ArduinoCore-avr library is downloaded from ArduinoCore.
Hardware: arduino uno (atmega328p)
Directory structure:
./ArduinoCore-avr/cores/arduino/Arduino.h
./main.c
./Makefile
main.c:
#ifndef F_CPU
#define F_CPU 16000000UL // or whatever may be your frequency
#endif
#include <avr/io.h>
#include <util/delay.h> // for _delay_ms()
#include "ArduinoCore-avr/cores/arduino/Arduino.h" // This line gave me error.
#define LED_PIN 13
int main(void)
{
DDRB=0b11100000;//pin 13 is in output mode
while (1) {
PORTB=0b11100000; //make pin 13 high and power on the led
_delay_ms(1000);
PORTB=0b11000000; //make pin 13 low and power off the led
_delay_ms(1000);
}
}
Makefile:
# Name: Makefile
# Author: <insert your name here>
# Copyright: <insert your copyright message here>
# License: <insert your license reference here>
# DEVICE ....... The AVR device you compile for
# CLOCK ........ Target AVR clock rate in Hertz
# OBJECTS ...... The object files created from your source files. This list is
# usually the same as the list of source files with suffix ".o".
# PROGRAMMER ... Options to avrdude which define the hardware you use for
# uploading to the AVR and the interface where this hardware
# is connected.
# FUSES ........ Parameters for avrdude to flash the fuses appropriately.
DEVICE = atmega328p
AVRDUDE_DEVICE = m328p
CLOCK = 16000000
PROGRAMMER = -c arduino -P /dev/tty.usbmodem1411
OBJECTS = main.o
FUSES = -U lfuse:w:0x64:m -U hfuse:w:0xdd:m -U efuse:w:0xff:m
HEADER = ArduinoCore-avr/cores/arduino/Arduino.h
######################################################################
######################################################################
# Tune the lines below only if you know what you are doing:
AVRDUDE = avrdude $(PROGRAMMER) -p $(AVRDUDE_DEVICE)
COMPILE = avr-gcc -Wall -Os -DF_CPU=$(CLOCK) -mmcu=$(DEVICE)
# symbolic targets:
all: main.hex
.c.o:
$(COMPILE) -c $< -o $#
.S.o:
$(COMPILE) -x assembler-with-cpp -c $< -o $#
# "-x assembler-with-cpp" should not be necessary since this is the default
# file type for the .S (with capital S) extension. However, upper case
# characters are not always preserved on Windows. To ensure WinAVR
# compatibility define the file type manually.
.c.s:
$(COMPILE) -S $< -o $#
flash: all
$(AVRDUDE) -U flash:w:main.hex:i
fuse:
$(AVRDUDE) $(FUSES)
install: flash fuse
# if you use a bootloader, change the command below appropriately:
load: all
bootloadHID main.hex
clean:
rm -f main.hex main.elf $(OBJECTS)
# file targets:
main.elf: $(OBJECTS)
$(COMPILE) -o main.elf $(OBJECTS)
main.hex: main.elf
rm -f main.hex
avr-objcopy -j .text -j .data -O ihex main.elf main.hex
# If you have an EEPROM section, you must also create a hex file for the
# EEPROM and add it to the "flash" target.
# Targets for code debugging and analysis:
disasm: main.elf
avr-objdump -d main.elf
cpp:
$(COMPILE) -E main.c
When compiling with the following command.
make
It shows the following error.
In file included from main.c:7:
ArduinoCore-avr/cores/arduino/Arduino.h:257:10: fatal error: pins_arduino.h: No such file or directory
#include "pins_arduino.h"
^~~~~~~~~~~~~~~~
compilation terminated.
I know that I have to add the library in my Makefile, but I don't know how to do that.
When including the header file in main.c, should I use #include "ArduinoCore-avr/cores/arduino/Arduino.h" or #include "Arduino.h".
The reason why I want to include Arduino.h file is that I want to use pinMode and digitalWrite function in my main.c. I don't want to reinvent the wheel (write the driver from scratch). Is that possible? I've tried to search the example code, but they all use arduino's default function which are loop and setup which is what I want to avoid.
Thank you.
Yes, it should be possible to the use Arduino AVR core code if you can manage to invoke the compiler in the right way to compile it and link it into your progam.
I am not going to give you an entire tutorial to solve all the problems you might find along the way. I think it will be sufficient to just point out how to solve the error you are currently getting, which is that pins_arduino.h is not found.
GCC has a list of directories called an include search path. When you #include a file, GCC searches the directories in the include search path for a file of that name. To make sure GCC can find pins_arduino.h, you need to locate the directory that has the right version of pins_arduino.h and add it to your include path using GCC's -I option. For example:
avr-gcc -Ipath/to/folder/ ...
The path can be relative or absolute but relative ones are easier to maintain and share with others.
I am learning linux, and my first step is to adapt my project for running on linux. Here is simple makefile (in educational purposes mostly), which generates out file:
#------------------------BUILD VARIABLES-----------------------------
# Directories, containing headers
INCLUDE_DIR = ../Include/
# Output directory which will contain output compiled file
OUTPUT_DIR = ../Bin/Debug/
SOURCES = EngineManager.cpp Geometry.cpp Main.cpp Model.cpp \
Shaders.cpp TGAImage.cpp
HEADERS = EngineManager.h Geometry.h Line.h Model.h Shaders.h \
TGAImage.h Triangle.h
#------------------------BUILD_RULES---------------------------------
TinyRenderBuilding : $(addprefix $(INCLUDE_DIR), $(HEADERS)) $(SOURCES)
mkdir -p $(OUTPUT_DIR)
g++ -std=c++14 -o $(OUTPUT_DIR)TinyRender.out -g -I$(INCLUDE_DIR) $(SOURCES)
I cannot understand, why does g++ not generate debug symbols? -g option is presented
To include debug symbols when compiling with g++ you need to pass the -g option.
In a make make file this usually means adding it to to CXXFLAGS.
Also make sure you pass the -g option when you create the executable: when you compile you turn .cpp files into .o files, when you do the linking you turn those .o files into your executable).
If you change the options before running make again be sure to run a make clean cause otherwise it won't get recompiled.
Finally, make sure that you do not have additional steps like strips command run on the executable (which would remove debugging symbols).
you can use
objdump --syms <executable-file>
to check if an executable have symbols.
when it doesn't have symbols it will say something like:
SYMBOL TABLE:
no symbols
(I'm no experto of C / C++ programming, I just run into this while I was trying to debug someone else code)
According to your makefile g++ should produce debug symbols (-g option is presented). To confirm this you can run file on resulting binary:
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9fe588c18099ef418daf288931bb033cc287922e, with debug_info, not stripped
(Note with debug_info string in output)
I'm not entirely sure, but you can try -g or -ggdb.You can do some research on these. We were using these parameters to debug the C program with the gdb tool.
I am looking for the clang equivalent of the cl command /FC. I need full paths for my build tool to parse out and open the code files with the errors.
https://msdn.microsoft.com/en-us/library/027c4t2s.aspx
CFLAGS+= -fdiagnostics-absolute-paths
You need to specify a fully-qualified or relative path to the file on the command-line instead of only passing in the filename. In the following example the debugger won't know where to find "blah.cc" because I compiled by specifying only the filename:
~ pwd
/mnt/scratch/myproject/src
~ clang++ blah.cc -c -o /mnt/scratch/myproject/build/blah.o
~ cd ../build
~ clang++ *.o -o myprogram
... however, if instead I'd done this:
~ pwd
/mnt/scratch/myproject
~ clang++ /mnt/scratch/myproject/src/blah.cc -c -o /mnt/scratch/myproject/build/blah.o
# or:
~ clang++ src/blah.cc -c -o build/blah.o
# ...
... then it embeds the fully-qualified or relative path into the debug sections.
If you use a partially qualified path, you'll have to tell GDB where to look for the code. You can look at the documentation for it here, though two gdb commands that may be helpful:
# This will cause gdb to look in "path2" instead of "path1"
(gdb) set substitute-path path1 path2
# This allows you to give a list of directories to search for your source.
# note that if you give relative paths on the command-line, it'll concatenate
# these paths and the relative path used at compile-time.
(gdb) set directories path [path ...]
I am bored to death with such behavior. So in SConstruct file we have the last string like this one:
import compilers, os
env = Environment(ENV = os.environ, TOOLS = ['default'])
def set_compiler(compiler_name):
env.Replace(FORTRAN = compiler_name)
env.Replace(F77 = compiler_name)
env.Replace(F90 = compiler_name)
env.Replace(F95 = compiler_name)
def set_flags(flags):
env.Replace(FORTRANFLAGS = flags)
env.Replace(F77FLAGS = flags)
env.Replace(F90FLAGS = flags)
env.Replace(F95FLAGS = flags)
mod_dir_prefix = {
"gfortran": "-J ",
"ifort": "-???",
"pgfortran": "-module "
}
flags = {
("gfortran", "debug"): "-O0 -g -Wall -Wextra -pedantic -fimplicit-none -fbounds-check -fbacktrace",
("gfortran", "release"): "-O3",
("pgfortran", "debug"): "-O0 -g -C -traceback",
("pgfortran", "release"): "-O4"
}
if not GetOption('clean'):
print "\nAvailable Fortran compilers:\n"
for k, v in compilers.compilers_dict().iteritems():
print "%10s : %s" % (k, v)
compiler = raw_input("\nChoose compiler: ")
set_compiler(compiler)
debug_or_release = raw_input("\nDebug or release: ")
set_flags(flags[(compiler, debug_or_release)])
env.Replace(FORTRANMODDIRPREFIX = mod_dir_prefix[compiler])
env.Replace(LINK = compiler)
env.Replace(LINKCOM = "$LINK -o $TARGET $LINKFLAGS $SOURCES $_LIBDIRFLAGS $_LIBFLAGS $_FRAMEWORKPATH $_FRAMEWORKS $FRAMEWORKSFLAGS")
env.Replace(LINKFLAGS = "")
env.Replace(FORTRANMODDIR = '#Mod')
Export('env')
SConscript('Sources/SConscript', variant_dir='Build', duplicate=0)
compilers.py is my own module to find some Fortran compilers which are available.
In Sources folder we have a couple of Fortran source files.
Sources\SConscript
Import('env')
env.Program('app', Glob('*.f90'))
Scons supports Fortran and everything works fine.
gfortran -o Temp\kinds.o -c -O3 -JMod Sources\kinds.f90
gfortran -o Temp\math.o -c -O3 -JMod Sources\math.f90
gfortran -o Temp\sorts.o -c -O3 -JMod Sources\sorts.f90
gfortran -o Temp\utils.o -c -O3 -JMod Sources\utils.f90
gfortran -o Temp\main.o -c -O3 -JMod Sources\main.f90
gfortran -o Temp\app.exe Temp\kinds.o Temp\main.o Temp\math.o Temp\sorts.o Temp\utils.o
scons: done building targets.
After renaming variant_dir name to let say #Bin or #Build we get error message:
gfortran -o Bin\kinds.o -c -O3 -JMod Sources\kinds.f90
gfortran -o Bin\main.o -c -O3 -JMod Sources\main.f90
Sources\main.f90:3.11:
USE sorts
1
Fatal Error: Can't open module file 'sorts.mod' for reading at (1): No such file or directory
Of course the order of compilation matters. But why it depends on variant_dir name? Seems like a bug, but maybe I'm doing something wrong.
P.S. This behavior doesn't depend on duplicate variable value.
P.P.S. Tested with SCons 2.0.1 on Windows with Python 2.7 and Mac OS X with Python 2.5.1.
This is a reply to an old thread, but I had virtually the same problem and needed to dig around for a solution.
Firstly, your build order is probably off because the dependency scanner for Fortran does not work properly. Try running
scons [your_arguments] -n --tree=all | less
which won't actually compile anything but show you the commands and in the end will print the dependency tree as Scons sees it.
A possible solution:
Try adding the line (I added your source for context):
env.Replace(FORTRANMODDIR = '#Mod')
env.Replace(FORTRANPATH = '.' ]
Export('env')
As far as I understand, paths are relative to the "virtual" location of the SConscript file (i.e. the src directory or the variant build directory), this should add the directory containing the source files to the scanner's search path.
In my version of scons (2.3.0), I cannot use the duplicate=0 argument, since it automatically inserts the original source directory into the module path, causing the command line to look like -module build/ -module src/ (ifort) and essentially overriding my preference not to clutter the source directory. This might be a bug, though.