htobe64 function disables debugger's ability to list source code - gdb

I have compiled the very simple program
$ cat main.cpp
#include <iostream>
int main() {
uint64_t val=1;
// val = htobe64(val);
std::cout << val << std::endl;
}
$ g++ -g main.cpp -o a.out
When I debug it using cgdb I get the following:
$ cgdb a.out
But when I uncomment the line // val = htobe64(val) something strange happens:
$ cat main.cpp
#include <iostream>
int main() {
uint64_t val=1;
val = htobe64(val);
std::cout << val << std::endl;
}
$ g++ -g main.cpp -o a.out
$ cgdb a.out
Uncommenting this single line causes cgdb to start showing the splash screen and when I type start as in the screenshot it only gives me assembler code (before cgdb started directly showing the source code and not its splash screen). Furthermore somehow the file path /home/user/byteswap.h appears in the screenshot, but this file does not exist (In this example user is was my username and /home/user my working directory).
Can someone tell me what is happening here and what I can do to be able to debug a program that is calling htobe64, i.e. how to achieve that cgdb will show me the source code as in the first example at the top?
Here are the tool versions:
$ cgdb --version
CGDB 0.7.1
Copyright 2002-2019 Bob Rossi and Mike Mueller.
CGDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for CGDB.
$ gdb --version
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 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.
$ g++ --version
g++ (Debian 11.2.0-10) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

When posting this questions I became aware of the fact that my g++ version is very new compared to my gdb version (I recently updated it to have better C++20 support).
I turns out that updating the gdb version solved the problem: With gdb version GNU gdb (Debian 10.1-2) 10.1.90.20210103-git the problem is no longer present. I admit that I should have verified this before posting but I do not delete the question because it may help others having similar strange obervations.

Related

Running C/C++ code with VS code always throw "exited with code=1 in 0.123 seconds"

I am trying to set up VScode to be able to the "Code Runner" package for C and C++ code with the Code Runner package, but it would always error with:
[Running] cd "d:\Desktop\Programming\For_fun\tester\" && g++ practice.cpp -o practice && "d:\Desktop\Programming\For_fun\tester\"practice
[Done] exited with code=1 in 0.123 seconds
I have discovered that compiling and running with wsl and ubuntu would work, but regular command prompt wouldn't. I presume that is a big indicator of what the problem is, but I have no idea how to resolve it or even start googling.
I am on Windows 10
This is my code:
#include <vector>
#include <iostream>
#include <string>
using namespace std;
int main() {
cout << "Hello World!\n";
return 0;
}
And these are the results of me trying to confirm whether I have the relevant packages installed:
PS D:\Desktop\Programming\For_fun\tester> c++ --version
c++.exe (MinGW.org GCC Build-20200227-1) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
PS D:\Desktop\Programming\For_fun\tester> gcc --version
gcc.exe (Rev5, Built by MSYS2 project) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
PS D:\Desktop\Programming\For_fun\tester> g++ --version
g++.exe (MinGW.org GCC Build-20200227-1) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks!
It doesn't work. But I fixed the problem: Basically, I used the windows finder to find all instances of gcc.exe and deleted the folders within my program files that house them. Then I removed their paths from my environment variables. Finally, I did a clean reinstall of gcc-core and gcc-g++ through cygwin and it worked

arm-none-eabi-g++: error: CreateProcess: No such file or directory

I have a problem with arm-none-eabi-g++ compiler running on Windows.
When I run my makefile on Ubuntu, everything works fine.
Makefile target fails on Windows with error
arm-none-eabi-g++: error: CreateProcess: No such file or directory
I'm using MingGW on Windows. MinGW, make and G++ locations are added to Win PATH.
Compiler and make are the same versions on both OS.
Ubuntu
getconf ARG_MAX
2097152
arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
make --version
GNU Make 4.1
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2014 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.
Windows 10 with MinGW
getconf ARG_MAX
32000
arm-none-eabi-g++ --version
arm-none-eabi-g++ (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
make --version
GNU Make 4.1
Built for i686-w64-mingw32
Copyright (C) 1988-2014 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.
More information
This is how one of my makefile targets look like
$(PROJECT).o: $(PROJECT).cpp
#echo start of $(#F)
$(CPP) $(CC_FLAGS) #./.symbols.txt -std=gnu++11 -fno-rtti #./.includes.txt -o $# $<
#echo end of $(#F)
Interesting thing is, that Windows build works fine only if the size of .symbols.txt and .includes.txt combined is lower than 32k. So it might look like it depends on ARG_MAX size (which is on MINGW 32k), but it's probably not true. Because another target in the same makefile looks like
$(PROJECT).elf: $(SYS_OBJECTS)
$(file > .sys_objects.txt, $(SYS_OBJECTS))
$(LD) $(LD_FLAGS) -T$(LINKER_SCRIPT) $(LIBRARY_PATHS) -o $# #./.sys_objects.txt $(LIBRARIES) $(LD_SYS_LIBS) $(LIBRARIES) $(LD_SYS_LIBS)
and it works well on Windows despite that sys_objects.txt size is about 90k.
Both $(LD) and variables $(CPP) variables are set to arm-none-eabi-g++.
Another thing I have noticed is that something on Windows adds a file like C:\Users\user\AppData\Local\Temp\ccQWU5K6.s to the end of g++ command (regardless if it fails or not). I have no clue where does this come from (maybe some MINGW support argument?).
Has anyone a clue why build fails on Windows with arguments bigger than 32k even if another target works fine with big arguments? Maybe it might be a coincidence.

Using SDL2 with g++ / MinGW crashes on launch

I am working on a game and recently made the transition from SDL 1.2 to SDL2 (kinda late to the party but heh). Despite having no compilation or linking error whatsoever, the program crashed on launch while stating (translated from French) "The application failed to start up correctly". At first I thought it was my own fault, but then I got suspicious and put together a quick SDL2 test, which indeed after flawless compilation crashed on launch.
Here is the code I've been using for this example (you can't make it more simple) :
#include <SDL.h>
int main(int argc, char *argv[])
{
return 0;
}
And the compilation line is g++ main.cpp -ISDL2-2.0.4\x86_64-w64-mingw32\include\SDL2 -LSDL2-2.0.4\x86_64-w64-mingw32\lib -lmingw32 -lSDL2main -lSDL2 -otest.exe -fpermissive -std=c++11 -Wno-write-strings -Wno-overflow
For what it's worth :
> g++ --version
g++ (x86_64-win32-seh, Built by MinGW-W64 project) 6.1.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I'm running MinGW-w64 on Windows, as you can see. The OS is Windows 8.1.
Welp. I actually used the wrong SDL2.dll. I feel dumb now.

objdump -W sees line numbers, objdump -drl and gdb don't? [duplicate]

I am trying to figure out a very strange issue. I have CentOS 6.5 system with gdb:
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
and gcc:
gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-8)
I have this file:
#include<stdio.h>
int main()
{
printf("OK!");
return 0;
}
which I compile with:
gcc -o a a.c -g -O0
The file seems to be fine:
$ file a
a: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
But when I try to debug it, this happens:
$ gdb a
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-75.el6)
Copyright (C) 2010 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".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from a...done.
(gdb) b main
Breakpoint 1 at 0x4004e4
(gdb) r
Starting program: a
Breakpoint 1, 0x00000000004004e4 in main ()
(gdb) l
1 /* Run time dynamic linker.
2 Copyright (C) 1995-2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
3 This file is part of the GNU C Library.
4
5 The GNU C Library is free software; you can redistribute it and/or
6 modify it under the terms of the GNU Lesser General Public
7 License as published by the Free Software Foundation; either
8 version 2.1 of the License, or (at your option) any later version.
9
10 The GNU C Library is distributed in the hope that it will be useful,
(gdb) l main
No line number known for main.
I.e., gdb refuses to see any debug information. Anybody has an idea what could be a problem here?
Your GDB is pretty old. Your GCC is fairly new.
I suspect that your GCC is emitting DWARF4 debug info (default as of gcc-4.8 according to release notes), which your GDB does not recognize.
Do you get better result with -gdwarf-2 instead of -g?
If so, upgrade your GDB or use -gdwarf-2 with this compiler.

gpuocelot llvm/Assembly/Parser.h: No such file or directory

I am using ubuntu 12.04
I have been trying to install gpuocelot for a few day now.
I recently installed llvm from the svn using
svn co http://llvm.org/svn/llvm­project/llvm/trunk llvm
./configure ­­enable­optimized
sudo make
sudo make install
But to do this I had to update gcc to 4.7 which i had also done
Now when i run sudo ./build.py --install
I keep on getting the following error
ocelot/ocelot/ir/implementation/ExternalFunctionSet.cpp:28:34: fatal error: llvm/Assembly/Parser.h: No such file or directory
The following outputs might be of help
z
aid#zaid-lappy:~/gpuocelot$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2013 NVIDIA Corporation
Built on Wed_Jul_17_18:36:13_PDT_2013
Cuda compilation tools, release 5.5, V5.5.0
zaid#zaid-lappy:~/gpuocelot$ gcc --version
gcc (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
zaid#zaid-lappy:~/gpuocelot$ g++ --version
g++ (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
zaid#zaid-lappy:~$ echo $PATH
/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/l/checkout/gpuocelot/ocelot/build_local/lib:/usr/local/cuda-5.5/bin
echo $LD_LIBRARY_PATH
/usr/local/cuda-5.5/lib64:
echo $LIBRARY_PATH returns blank
The LLVM C++ API, including the very existence and location of headers, is very unstable. This is why projects usually align themselves to some official release of LLVM, and I'm sure GPUOcelot follows the same pattern.
In top-of-tree LLVM, the header llvm/Assembler/Parse.h doesn't exist, which is why you can't find it. You should compile & link GPUOcelot vs. the LLVM version it supports officially. If GPUOcelot tries to follow the top-of-tree of LLVM, at least there should be a "known good revision" with which it works.