Program freezes under gdb when exception occurs - debugging

I compiled with g++ a simple test program:
int main()
{
try
{
printf("before\n");
throw 1;
}
catch(int i)
{
printf("catched int\n");
}
catch(...)
{
printf("catched(...)\n");
}
}
Normally works ok with or without debug info included.
But when debugged with gdb it always hangs on "throw 1;" line so I'm not able to debug programs, that normally throws exceptions.
The last information from debugger is:
Catchpoint 1 (exception thrown), 0x00007ffff7b8f9e0 in __cxa_throw () from /usr/lib/libstdc++.so.6
My compilation and linking options:
g++ -Wshadow -Wunreachable-code -Wswitch-enum -Wswitch-default -Wextra -Wall -pg -g -m64 -c main.cpp
g++ -o exec/exception_problem obj/main.o -pg
My environment:
ubuntu 10.10, 64bit;
g++/gcc 4.4.5;
gdb 7.2;
debugged under codeblocks svn rev 7440
Any ideas what is the problem?
Additional info:
Last two lines of gdb log are:
Catchpoint 1 (exception thrown), 0x00007ffff7b8f9e0 in __cxa_throw () from /usr/lib/libstdc++.so.6
>>>>>>cb_gdb:
The last character in log is colon.
gdb commandline:
/usr/bin/gdb -nx -fullname -quiet -args exec/exception_problem
I did not found any *gdbinit* in my home directory; global gdbinit is empty. Is it possible that codeblocks prepares specific gdbinit and puts it to gdb?
Best regards for all.

Catchpoint 1 (exception thrown) ...
Is there something in your .gdbinit that you haven't told us about? (Perhaps catch throw ?)
Is the Catchpoint 1 really the last line that GDB prints? Here is what I see:
Reading symbols from /tmp/a.out...done.
Catchpoint 1 (throw)
(gdb) run
before
Catchpoint 1 (exception thrown), __cxxabiv1::__cxa_throw (obj=0x602090, tinfo=0x601060, dest=0) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:70
70 ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc: No such file or directory.
in ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc
(gdb) c
catched int
[Inferior 1 (process 16008) exited normally]
(gdb) q

Related

Why does macOS kill static executables created by clang?

I have a minimal c program for the m1 arm cpu that returns 42:
void _start() {
asm("mov x0, #42;");
asm("mov x16, #1;");
asm("svc 0x80;");
}
This code compiles after telling clang to use the _start symbol and returns the correct value.
clang -Wl,-e, -Wl,__start test.c -o dyn.out
./dyn.out ; echo $?
42
However this binary still has dynamic links according to otool:
otool -L ./dyn.out
./dyn.out:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
After telling clang to produce a unsigned static binary however macOS then immediately kills the binary when trying to run.
clang -Wl,-e, -Wl,__start -static -nostdlib test.c -o static_no_sign.out
zsh: killed ./static_no_sign.out
Signing the binary before running also produces the same problem.
clang -Wl,-e, -Wl,__start -static -nostdlib test.c -o static_sign.out
codesign -s - static_sign.out
./static_sign.out
zsh: killed ./static_sign.out
The following messages are produced in Console:
taskgated: UNIX error exception: 3
taskgated: no signature for pid=93166 (cannot make code: UNIX[No such process])
But codesign can verify the signature
codesign -v -v static_sign.out
static_sign.out: valid on disk
static_sign.out: satisfies its Designated Requirement
Can anyone clarify why macOS is deciding to kill the clang produced binaries?
Because static binaries are explicitly disallowed on any architecture other than x86_64.
XNU contains this code piece in the Mach-O loader:
case MH_EXECUTE:
if (depth != 1 && depth != 3) {
return LOAD_FAILURE;
}
if (header->flags & MH_DYLDLINK) {
/* Check properties of dynamic executables */
if (!(header->flags & MH_PIE) && pie_required(header->cputype, header->cpusubtype & ~CPU_SUBTYPE_MASK)) {
return LOAD_FAILURE;
}
result->needs_dynlinker = TRUE;
} else if (header->cputype == CPU_TYPE_X86_64) {
/* x86_64 static binaries allowed */
} else {
/* Check properties of static executables (disallowed except for development) */
#if !(DEVELOPMENT || DEBUG)
return LOAD_FAILURE;
#endif
}
break;
If you do the exact same thing on x86_64, it works:
void _start()
{
__asm__ volatile
(
".intel_syntax noprefix\n"
"mov eax, 0x2000001\n"
"mov edi, 42\n"
"syscall"
);
}
% clang -Wl,-e,__start -static -nostdlib t.c -o t -arch x86_64
% ./t
% echo $?
42

Can't get rid of "value has been optimized out" in GDB

I am debugging the CPython executable by GDB and can't get the value of some variables despite of disabling all GCC optimizations:
(gdb) print *co
value has been optimized out
(gdb) frame
#0 _PyEval_EvalFrameDefault (
f=Frame 0x7ffff7f36050, for file <frozen importlib._bootstrap>, line 8, in <module> (),
throwflag=<optimized out>) at Python/ceval.c:1057
1057 switch (opcode) {
(gdb) info locals
stack_pointer = 0x7ffff7f361c8
next_instr = 0x555555aff422
opcode = 100
oparg = 0
fastlocals = 0x7ffff7f361c8
freevars = <optimized out>
retval = 0x0
tstate = <optimized out>
co = <optimized out>
instr_ub = -1
instr_lb = 0
instr_prev = -1
first_instr = <optimized out>
names = <optimized out>
consts = <optimized out>
... <output cropped>
OS: Ubuntu 18.04.2 LTS
CPython version: 3.8.0a
Compiled by: GCC 7.3.0 on Linux
Debugger: GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
Firstly, I did the usual compilation with --with-pydebug option.
./configure --with-pydebug
make -s -j
It should preserve all values for debugger but it doesn't.
I have read, that the cause of this problem is the compiler optimization, so I decided to disable it completely.
For this I changed relevant lines in the configure script from:
# Optimization messes up debuggers, so turn it off for
# debug builds.
if "$CC" -v --help 2>/dev/null |grep -- -Og > /dev/null; then
OPT="-g -Og -Wall"
else
OPT="-g -O0 -Wall"
fi
to:
# Optimization messes up debuggers, so turn it off for
# debug builds.
# if "$CC" -v --help 2>/dev/null |grep -- -Og > /dev/null; then
# OPT="-g -Og -Wall"
# else
# OPT="-g -O0 -Wall"
# fi
OPT="-g -O0 -Wall"
The resulting optimization options in the Makefile are:
$ grep -- '-O' Makefile
OPT= -g -O0 -Wall
$(MAKE) all CFLAGS="$(CFLAGS) -O0 -pg -fprofile-arcs -ftest-coverage" LIBS="$(LIBS) -lgcov"
$(PYTHON_FOR_BUILD) -Wi -O $(DESTDIR)$(LIBDEST)/compileall.py \
$(PYTHON_FOR_BUILD) -Wi -OO $(DESTDIR)$(LIBDEST)/compileall.py \
$(PYTHON_FOR_BUILD) -Wi -O $(DESTDIR)$(LIBDEST)/compileall.py \
$(PYTHON_FOR_BUILD) -Wi -OO $(DESTDIR)$(LIBDEST)/compileall.py \
Also, didn't help.
The question: Why "the value has been optimized out" persists even with the compiler optimization disabled and how can I overcome this problem?
EDIT
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7dd5f10 0x00007ffff7df4b20 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7bbbbb0 0x00007ffff7bca0f1 Yes /lib/x86_64-linux-gnu/libpthread.so.0
0x00007ffff79b2e50 0x00007ffff79b3bde Yes /lib/x86_64-linux-gnu/libdl.so.2
0x00007ffff77afe70 0x00007ffff77b093a Yes /lib/x86_64-linux-gnu/libutil.so.1
0x00007ffff741ca80 0x00007ffff74db2f5 Yes /lib/x86_64-linux-gnu/libm.so.6
0x00007ffff70412d0 0x00007ffff71b9c3c Yes /lib/x86_64-linux-gnu/libc.so.6

gcc warning different when using --preprocessed

When compiling ltrace with icecc we run into a compilation problem. This is the minimal example:
main.c
#include <assert.h>
int main(int argc, char **argv) {
assert(argc != argc);
return 0;
}
test.sh:
#!/bin/bash
set -x
# one step compilation (no warning)
gcc -Wall main.c
# splitted compilation (warning)
gcc -Wall -E main.c -o main.i
gcc -Wall --preprocessed main.i
output:
++ gcc -Wall main.c
++ gcc -Wall -E main.c -o main.i
++ gcc -Wall --preprocessed main.i
main.c: In function ‘main’:
main.c:4:10: warning: self-comparison always evaluates to false [-Wtautological-compare]
assert(argc != argc);
^~
As you can see the result is different when compiling in one step and when preprocessing and compiling in two steps. Is this intended behavior?
I use gcc 6.3, the issue also appears in gcc 6.2 for ARM. I also cannot ignore this, as the full example uses -Werror.

Linker error compiling mex with mingw-w64

I'm trying to setup Mingw-w64 as the mex compiler in MATLAB 2013a. My laptop has x86_64 architecture and runs windows 7. The program I want to compile uses c++11-style threading, so I'm using mingw-w64 version 4.9.0 with posix threads.
According to instruction I found here and here, I modified my mexopts.bat file. The code seems to compile successfully, but the linker reports an error. Does anyone have suggestions what I might be doing wrong?
By the way, I tried using gnumex to setup the compiler, but that didn't work either.
Here's the output and error message that MATLAB gives:
>mex -v Gomoku_mex.cpp
-> Default options filename found in C:\Users\Bas\AppData\Roaming\MathWorks\MATLAB\R2013a
-> Options file = C:\Users\Bas\AppData\Roaming\MathWorks\MATLAB\R2013a\mexopts.bat
MATLAB = C:\Program Files\MATLAB\R2013a
-> COMPILER = x86_64-w64-mingw32-g++
-> Compiler flags:
COMPFLAGS = -std=c++11 -fexceptions -I"C:\Program Files\MATLAB\R2013a\extern\include"
OPTIMFLAGS = -O3 -fexpensive-optimizations -DNDEBUG
DEBUGFLAGS = -g -Wall -Wextra
arguments =
Name switch = -o
-> Pre-linking commands=
-> LINKER = x86_64-w64-mingw32-g++
-> Link directives:
LINKFLAGS = -shared mex.def -L"C:\Program Files\MATLAB\R2013a\bin\win64" -static-libstdc++
LINKDEBUGFLAGS = -g -Wall
LINKFLAGSPOST = -lmex -lmx -lmat -lmwlapack -lmwblas
Name directive = -o "Gomoku_mex.mexw64"
File link directive =
Lib. link directive =
Rsp file indicator =
-> Resource Compiler =
-> Resource Linker =
----------------------------------------------------------------
--> x86_64-w64-mingw32-g++ -std=c++11 -fexceptions -I"C:\Program Files\MATLAB\R2013a\extern\include" -oC:\Users\Bas\AppData\Local\Temp\mex_r7jRw0\Gomoku_mex.obj -I"C:\Program Files\MATLAB\R2013a\extern\include" -I"C:\Program Files\MATLAB\R2013a\simulink\include" -O3 -fexpensive-optimizations -DNDEBUG -DMX_COMPAT_32 Gomoku_mex.cpp
C:\Users\Bas\AppData\Local\Temp\cc4hwD3A.o:Gomoku_mex.cpp:(.text+0x9d1c): undefined reference to `mxGetPr'
C:\Users\Bas\AppData\Local\Temp\cc4hwD3A.o:Gomoku_mex.cpp:(.text+0x9d83): undefined reference to `mxCreateDoubleScalar'
C:/PROGRA~1/mingw-w64/x86_64-4.9.0-posix-seh-rt_v3-rev2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\Bas\AppData\Local\Temp\cc4hwD3A.o: bad reloc address 0x0 in section `.pdata$_ZNKSt5ctypeIcE8do_widenEc'
collect2.exe: error: ld returned 1 exit status
C:\PROGRA~1\MATLAB\R2013A\BIN\MEX.PL: Error: Compile of 'Gomoku_mex.cpp' failed.
Error using mex (line 206)
Unable to complete successfully.
Edit: As extra information, this is my mexopts.bat file. I got this directly from one of the two links above and modified directory & compiler names and added -std=c++11
set MATLAB=%MATLAB%
set PATH=%PATH%;C:\PROGRA~1\mingw-w64\x86_64-4.9.0-posix-seh-rt_v3-rev2\mingw64\bin
set MW_TARGET_ARCH=win64
rem ********************************************************************
rem Compiler parameters
rem ********************************************************************
set COMPILER=x86_64-w64-mingw32-g++
set COMPFLAGS=-std=c++11 -fexceptions -I"%MATLAB%\extern\include"
set OPTIMFLAGS=-O3 -fexpensive-optimizations -DNDEBUG
set DEBUGFLAGS=-g -Wall -Wextra
set NAME_OBJECT=-o
rem ********************************************************************
rem Linker parameters
rem ********************************************************************
set PRELINK_CMDS1=echo EXPORTS > mex.def & echo mexFunction >> mex.def
set LINKER=x86_64-w64-mingw32-g++
set LINKFLAGS= -static-libstdc++ -shared mex.def -L"%MATLAB%\bin\win64" -L"%MATLAB%\extern\lib\win64\microsoft"
set LINKFLAGSPOST= -lmex -lmx -lmat -lmwlapack -lmwblas
set LINKOPTIMFLAGS=-O3
set LINKDEBUGFLAGS= -g -Wall
set LINK_FILE=
set LINK_LIB=
set NAME_OUTPUT=-o "%OUTDIR%%MEX_NAME%%MEX_EXT%"
set RSP_FILE_INDICATOR=
set POSTLINK_CMDS1=del mex.def
Take the following configuration file that I'm using (you'll need to adjust the path pointing to MinGW-w64 location accordingly):
mingw_mexopts.bat
#echo off
set MATLAB=%MATLAB%
set MW_TARGET_ARCH=win64
set PATH=C:\MinGW-w64\mingw64\bin;%PATH%
set COMPILER=x86_64-w64-mingw32-g++
set COMPFLAGS=-c -m64 -mwin32 -mdll -Wall -std=c++11 -DMATLAB_MEX_FILE
set OPTIMFLAGS=-DNDEBUG -O2
set DEBUGFLAGS=-g
set NAME_OBJECT=-o
set LINKER=x86_64-w64-mingw32-g++
set LINKFLAGS=-shared -L"%MATLAB%\extern\lib\win64\microsoft" -L"%MATLAB%\bin\win64"
set LINKFLAGSPOST=-lmx -lmex -lmat
set LINKOPTIMFLAGS=-O2
set LINKDEBUGFLAGS=-g
set LINK_FILE=
set LINK_LIB=
set NAME_OUTPUT=-o "%OUTDIR%%MEX_NAME%%MEX_EXT%"
Next here is a simple MEX-function that uses C++11 threads:
test.cpp
#include "mex.h"
#include <vector>
#include <thread>
void say_hello(int tid) {
mexPrintf("hello from %d\n", tid);
}
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
std::vector<std::thread> threads;
for (int i=0; i<10; i++) {
threads.push_back(std::thread(say_hello, i));
}
for(auto& t : threads) {
t.join();
}
}
Finally we compile and run it in MATLAB:
>> mex -f mingw_mexopts.bat -largeArrayDims test.cpp
>> setenv('PATH', ['C:\MinGW-w64\mingw64\bin;', getenv('PATH')])
>> test
hello from 0
hello from 4
hello from 2
hello from 3
hello from 5
hello from 1
hello from 6
hello from 8
hello from 7
hello from 9
Note that if you're going to deploy this to another machine, you'll have to also copy a few dependent DLL's (you'll find them in MinGW bin folder), and place them next to the MEX-file. Use Dependency Walker to list them. In my case it was:
libstdc++-6.dll
libgcc_s_seh-1.dll
libwinpthread-1.dll
I am using GCC 4.8.2 with MATLAB R2014a running on 64-bit Windows.
Note these error messages:
C:\Users\Bas\AppData\Local\Temp\cc4hwD3A.o:Gomoku_mex.cpp:(.text+0x9d1c): undefined reference to `mxGetPr'
C:\Users\Bas\AppData\Local\Temp\cc4hwD3A.o:Gomoku_mex.cpp:(.text+0x9d83): undefined reference to `mxCreateDoubleScalar'
The library search path for libmex, libmx, libmat, ... is not added in your link command. The directory in your script is the bin directory containing DLLs. That's not correct here.
LINKFLAGS = -shared mex.def -L"C:\Program Files\MATLAB\R2013a\extern\lib\win64\microsoft" -static-libstdc++

inline functions have "first defined here" and "multiple defenition"

Like two of my previous questions (inline-asm-with-gcc & arm7tdmi-does-not-support-requested-special-purpose-register, I have some build problem when converting code compiled with ARMASM to gcc(code sourcery GCC-4.6.2 eabi).
This time is at linking process: I get a lot of "first defined here" and "multiple definition" to inline functions. Example :
inline U16 ByteSwap16(U16 uData) {
return ( (uData >> 8) | (uData << 8) );
}
I get " multiple definition of `ByteSwap16' " and "first defined here" on the first line.
Here's the linking parameter that I use for the file with the error :
arm-none-eabi-ld -T".\linker.ld" -Map=BootLoad.map -o BootLoad.elf InitMain.o tsk_main.o ecp.o memalloc.o tsk_ecp.o firmdesc.o crc.o flash.o eth.o firmflash.o firmdest.o bcfg.o bootdownload.o cinit.o serial.o cpu.o mmu.o ngucos.o cdbini.o cs712sio.o cs712eth.o nginit.o MmuSdram0.o ../../OS/ngos/lib/rtstub/arm/gcc/libngosd4m32l.a ../../OS/ngip/lib/rtstub/arm/gcc/libngipd4m32l.a
In case the error comes in compilation process :
arm-none-eabi-gcc -c -H -Wall -Wa,-adhlns="tsk_main.o.lst" -fmessage-length=0 -MMD -MP -MF"tsk_main.d" -MT"tsk_main.d" -fpic -o"tsk_main.o" -march=armv4t -mcpu=arm7tdmi -mlittle-endian -g3 -gdwarf-2 -O0 -I"../../OS/ngos/hw/cdb89712" -I"../../OS/ngos" -I"../../OS/ngos/include" -I"../../OS/ngos/rtos/ucosii" -I"./" -I"src/" -I"../../Common/inc" -I"../../OS/uCOS-II/SOURCE" -I"../../OS/ngos/drivers/arm" -I"../../OS/ngos/include/ngos" -I"../../OS/ngip/include" -I"../../OS/ngip/include/ngip" -I"../../Dvcscomponent/Inc" -I"../../Inc" "src/tsk_main.c"
Any idea why the inline function generate theses errors?
Thanks in advance!

Resources