Debugger in C::B. Can't open cygwin.S - c

Hi I just discovered a quite weird behaviour of the debugger when declaring a simple two-dimensional array. It looks like it can't open a file cygwin.S in the library.
Cannot open file: ../../../../../src/gcc-4.8.1/libgcc/config/i386/cygwin.S
At ../../../../../src/gcc-4.8.1/libgcc/config/i386/cygwin.S:169
An execution without debugging works fine. There is an example of the code:
#include <stdio.h>
#include <stdlib.h>
int main()
{
const int strNumTries = 15;
const int strLength = 98;
char strName[strLength][strNumTries];
printf("Hello world!\n");
return 0;
}
Debugger stops on the char array declaration using 'step in' method. So what's the problem it may be?

I suspect your seeing something like this:
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 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. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from untitled...done.
(gdb) br main
Breakpoint 1 at 0x4005f1: file untitled.c, line 6.
(gdb) r
Starting program: /home/xxxx/untitled
.
.
.
Breakpoint 1, main () at untitled.c:6
6 const int strNumTries = 15;
(gdb) s
7 const int strLength = 98;
(gdb)
8 char strName[strLength][strNumTries];
(gdb)
10 printf("Hello world!\n");
(gdb)
_IO_puts (str=0x400794 "Hello world!") at ioputs.c:34
34 ioputs.c: No such file or directory.
(gdb)
36 in ioputs.c
(gdb)
strlen () at ../sysdeps/x86_64/strlen.S:66
66 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb)
67 in ../sysdeps/x86_64/strlen.S
(gdb)
68 in ../sysdeps/x86_64/strlen.S
where that last line repeats many times before moving on to any other sub functions.
This is not an error, but rather part of the call to printf()
the following is the only gdb output that has anything to do with the array declaration:
8 char strName[strLength][strNumTries];

Not sure if this will help your situation, but ...
I had exactly the same errors from GDB, and GDB admitted it had failed and had a problem (see GDB listing below). I could reproduce this with GCC/gFortran 6.4 and 7.1 100% (running C::B under Win, with MingW).
Of course, I had not ever installed cygwin, and I only use seh and sjlj variants of the MingW64 compilers. Also, I don't have, and never had any of the dir's that GDB is complaining about (e.g. "/../src/gcc-7.1.0/") so it made no sense ... and the problem arose only after adding one more ostensibly similar s/r to my lib of thousands of s/r's (none of which ever complained about this).
... to make a long story short, the problem turned out to be "out of stack space", as I had declared some (Automatic) arrays with large size. Changing either the array sizes (smaller) or changing the Automatic arrays to Allocatable arrays (the former goes on the stack, the later on the heap) fixed the problem.
... so, GDB seems to have a bug, and its complaints had nothing to do with the actual error.
---- for completeness, here is the relevant portion of my GDB listing:
[debug][New Thread 740.0x9fc]
[debug]172 ../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S: No such file or directory.
[debug]Thread 1 received signal SIGSEGV, Segmentation fault.
[debug]__chkstk_ms () at ../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S:172
[debug]>>>>>>cb_gdb:
[debug]> info frame
[debug]Stack level 0, frame at 0x136f00:
[debug] eip = 0x664974bb in __chkstk_ms (../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S:172); saved eip = 0x664958b3
[debug] called by frame at 0x136f14
[debug] source language asm.
[debug] Arglist at 0x136ef8, args:
[debug] Locals at 0x136ef8, Previous frame's sp is 0x136f00
[debug] Saved registers:
[debug] eax at 0x136ef4, ecx at 0x136ef8, eip at 0x136efc
[debug]>>>>>>cb_gdb:
Cannot open file: ../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S
At ../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S:172
[debug]> info locals
[debug]No locals.
[debug]>>>>>>cb_gdb:
[debug]> info args
[debug]No symbol table info available.
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]../../../../src/gdb-7.11.1/gdb/dwarf2loc.c:364: internal-error: dwarf_expr_frame_base: Assertion `framefunc != NULL' failed.
[debug]A problem internal to GDB has been detected,
[debug]further debugging may prove unreliable.
[debug]This is a bug, please report it. For instructions, see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]This application has requested the Runtime to terminate it in an unusual way.
[debug]Please contact the application's support team for more information.
[debug]#0 __chkstk_ms () at ../../../../../src/gcc-7.1.0/libgcc/config/i386/cygwin.S:172
[debug]#1 0x664958b3 in fadcern_sixtrack_xl (
Debugger finished with status 1

I received this error when i was trying to debug using gdb in vscode. Vscode don't offer redirected input especially for C. So i was using freopen(). Everything worked fine until it stepped into the declaration part of array.
int arr[n]
So I replaced it with a pointer and allocated memory dynamically.
int *arr=(int *) malloc(sizeof(int)*n);
and this worked.
I think gdb is unable to handle those arr[variable] declaration. But I may be completely wrong. Hope this helps.

Related

Conditional data watchpoint doesn't work in ARM GDB

My intent is to be able to catch when a global variable has some exact value. GDB has data watchpoints according to which this can be implemented.
Consider this simple program written for x86 Linux:
int myVar = 0;
void debug_watchpoints() {
for(int i=0; i < 2000; i++) {
myVar++;
}
}
int main() {
debug_watchpoints();
return 0;
}
Compiling the program with
gcc -o main -ggdb3 -Og main.c
And starting debugging with GDB:
max#PC-LT-23:~/stackoverflow$ gdb ./main
GNU gdb (Ubuntu 8.3-0ubuntu1) 8.3
Copyright (C) 2019 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
(gdb) b main
Breakpoint 1 at 0x1146: file main.c, line 9.
(gdb) start
Temporary breakpoint 2 at 0x1146: file main.c, line 9.
Starting program: /home/max/stackoverflow/main
Breakpoint 1, main () at main.c:9
9 int main() {
(gdb) watch myVar if myVar==1337
Hardware watchpoint 3: myVar
(gdb) continue
Continuing.
Hardware watchpoint 3: myVar
Old value = 1336
New value = 1337
debug_watchpoints () at main.c:4
4 for(int i=0; i < 2000; i++) {
(gdb)
As you can see it halted the program at exactly the point in time when the variable was set to 1337.
Consider the exact same program, compiled with arm-none-eabi-gcc for a STM32L476RG microcontroller which has a Cortex-M4F core. The used IDE here is System Workbench for STM32 (aka Eclipse) with a project generated by STM32CubeMX.
Now launching openocd gives
Open On-Chip Debugger 0.10.0+dev-00021-g524e8c8 (2019-04-12-08:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_assert_srst
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
padded zone erase set to 1
adapter speed: 8000 kHz
adapter_nsrst_delay: 100
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 8000 kHz
Info : STLINK v2.1 JTAG v34 API v2 M25 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 0.011074
Error: target voltage may be too low for reliable debugging
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Stlink adapter speed set to 4000 kHz
Info : STM32L476RGTx.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08001340 msp: 0x20018000
A breakpoint is set in the main function and then the watchpoint is setup exactly like before. Also, a breakpoint is is set after the execution of the debug_watchpoints() function.
GNU gdb (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 8.3.0.20190709-git
Copyright (C) 2019 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 "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) Reset_Handler () at ../startup/startup_stm32l476xx.s:63
63 ldr sp, =_estack /* Set stack pointer */
Temporary breakpoint 3, main () at ../Src/main.c:65
65 {
(gdb) watch myVar if myVar==1337
Hardware watchpoint 4: myVar
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x08000f46 in main at ../Src/main.c:70
4 hw watchpoint keep y myVar
stop only if myVar==1337
(gdb)
When continuing the program, it now stops at every modification of the variable with a SIGTRAP, regardless of whether the condition was met or not.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08000ec2 in debug_watchpoints () at ../Src/main.c:54
54 for(int i=0; i < 2000; i++) {
(gdb) continue
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08000ec2 in debug_watchpoints () at ../Src/main.c:54
54 for(int i=0; i < 2000; i++) {
(gdb) continue
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08000ec2 in debug_watchpoints () at ../Src/main.c:54
54 for(int i=0; i < 2000; i++) {
(gdb) info breakpoint
Num Type Disp Enb Address What
2 breakpoint keep y 0x08000f46 in main at ../Src/main.c:70
4 hw watchpoint keep y myVar
stop only if myVar==1337
(gdb) print myVar
$2 = 3
I can continue for as many times as I want, it just breaks each and every time the variable is changed.
In my scenario of "debugging a memory corruption on the stack", I really need GDB to evaluate the condition correctly, otherwise the program stops a thousand times or more (every time a variable which happens to be at this memory location is changed) and not at only the specific time a specific value is written into it to catch a bug.
Why does arm-none-eabi-gdb differ here in its behavior from normal gdb? Could the error lie in the Cortex-M4 hardware debugging capabilities, arm-none-eabi-gdb, or openocd as the GDB server?
As said, there's no working implementation in openocd, the debugger bridge you are using.
You can set by sw. Here a small snippet. COMP2, FUNCTION2, COMP1 and FUNCTION1 are DWT registers. Please note that you need to use two comparators linked together. Not all Cortex-m implementations support these features and not all comparators are linkable, it depends on your silicon. Also it seems that the capture is asynchonous. Generally my PC stops a few istruction after the trigger.
DWT->COMP2 = <address to compare>;
DWT->FUNCTION2 = 0;
DWT->COMP1 = <word to compare>;
DWT->FUNCTION1 = 0x20B06;
None of the software I know does it out of the box. When |I use the DWT usually I set it in my software. I have not found any way to program it via any variant of gdb (except manual setting the registers - but it is too annoying)

How to fix GDB not finding file: "../sysdeps/unix/sysv/linux/raise.c:50"

We're learning to use GDB in my Computer Architecture class. To do this we do most of our work by using SSH to connect to a raspberry pi. When running GDB on some code he gave us to debug though it ends with an error message on how it can't find raise.c
I've tried:
installing libc6, libc6-dbg (says they're already up-to-date)
apt-get source glibc (gives me: "You must put some 'source' URIs in your sources.list")
https://stackoverflow.com/a/48287761/12015458 (apt source returns same thing as the apt-get source above, the "find $PWD" command the user gave returns nothing)
I've tried looking for it manually where told it may be? (/lib/libc doesn't exist for me)
This is the code he gave us to try debugging on GDB:
#include <stdio.h>
main()
{
int x,y;
y=54389;
for (x=10; x>=0; x--)
y=y/x;
printf("%d\n",y);
}
However, whenever I run the code in GDB I get the following error:
Program received signal SIGFPE, Arithmetic exception.
__GI_raise (sig=8) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
I asked him about it and he didn't really have any ideas on how to fix it.
It does not really matter that the source for raise() is not found. It would only show you the line where the exception is finally raised, but not the place where the error is triggered.
Run the erroneous program again in GDB. And when the exception is raised, investigate the call stack and the stackframes with GBDs commands. This is the point in your task, so I won't give you more than this hint.
If you're clever you can see the error in the given source just by looking at it. ;-)
When GDB does not know any symbol, you need to compile with the option -g to get debugger support.
EDIT
Now on a Windows system this is my log (please excuse the colouring, I didn't found a language selector for pure text):
D:\tmp\StackOverflow\so_027 > type crash1.c
#include <stdio.h>
main()
{
int x,y;
y=54389;
for (x=10; x>=0; x--)
y=y/x;
printf("%d\n",y);
}
D:\tmp\StackOverflow\so_027 > gcc crash1.c -g -o crash1.out
crash1.c:2:1: warning: return type defaults to 'int' [-Wimplicit-int]
main()
^~~~
D:\tmp\StackOverflow\so_027 > dir
[...cut...]
04.09.2019 08:33 144 crash1.c
04.09.2019 08:40 54.716 crash1.out
D:\tmp\StackOverflow\so_027 > gdb crash1.out
GNU gdb (GDB) 8.1
[...cut...]
This GDB was configured as "x86_64-w64-mingw32".
[...cut...]
Reading symbols from crash1.out...done.
(gdb) run
Starting program: D:\tmp\StackOverflow\so_027\crash1.out
[New Thread 4520.0x28b8]
[New Thread 4520.0x33f0]
Thread 1 received signal SIGFPE, Arithmetic exception.
0x0000000000401571 in main () at crash1.c:7
7 y=y/x;
(gdb) backtrace
#0 0x0000000000401571 in main () at crash1.c:7
(gdb) help stack
Examining the stack.
The stack is made up of stack frames. Gdb assigns numbers to stack frames
counting from zero for the innermost (currently executing) frame.
At any time gdb identifies one frame as the "selected" frame.
Variable lookups are done with respect to the selected frame.
When the program being debugged stops, gdb selects the innermost frame.
The commands below can be used to select other frames by number or address.
List of commands:
backtrace -- Print backtrace of all stack frames
bt -- Print backtrace of all stack frames
down -- Select and print stack frame called by this one
frame -- Select and print a stack frame
return -- Make selected stack frame return to its caller
select-frame -- Select a stack frame without printing anything
up -- Select and print stack frame that called this one
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) next
Thread 1 received signal SIGFPE, Arithmetic exception.
0x0000000000401571 in main () at crash1.c:7
7 y=y/x;
(gdb) next
[Inferior 1 (process 4520) exited with code 030000000224]
(gdb) next
The program is not being run.
(gdb) quit
D:\tmp\StackOverflow\so_027 >
Well, it marks directly the erroneous source line. That is different to your environment as you use a Raspi. However, it shows you some GDB commands to try.
Concerning your video:
It is clear that inside raise() you can't access x. That's why GDB moans about it.
If an exception is raised usually the program is about to quit. So there is no value in stepping forward.
Instead, as shown in my log, use GDB commands to investigate the stack frames. I think this is the issue you are about to learn.
BTW, do you know that you should be able to copy the screen content? This will make reading so much easier for us.
From a practical standpoint the other answer is correct, but if you do want the libc sources:
apt-get source is the right way to get the sources of libc, but yes, you do need to have source repositories configured in /etc/apt/sources.list.
If you're using Ubuntu, see the deb-src lines in https://help.ubuntu.com/community/Repositories/CommandLine
For debian, see https://wiki.debian.org/SourcesList#Example_sources.list
Then apt-get source should work. Remember to tell GDB where those sources are using the "directory" command.

GDB symbols missing - libc claimed to be wrong library or version mismatch

I am having trouble showing proper debug symbols in the backtrace in GDB in an ARM cross-compiled system, built using Yocto.
abc.c is a simple printf("Hello world\n"); program in C (nothing tricky). On the build machine:
> yocto-dir/build/tmp-angstrom-glibc/sysroots/x86_64-linux/usr/bin/arm-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gcc abc --sysroot=yocto-dir/build/tmp-angstrom-glibc/sysroots/imx28scm -g -O0 -o abc
> scp abc root#DEVICE-IP:~
On the ARM target:
> gdbserver :2345 abc
Start GDB on the build machine (from installed Yocto SDK):
> /usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/arm-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gdb abc
GNU gdb (Linaro GDB) 7.8-2014.09
Copyright (C) 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. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-angstromsdk-linux --target=arm-angstrom-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.linaro.org>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from abc...done.
(gdb) target remote DEVICE-IP:2345
Remote debugging using DEVICE-IP:2345
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Cannot access memory at address 0x0
0x4ae90a20 in ?? ()
(gdb) bt
#0 0x4ae90a20 in ?? ()
#1 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) set sysroot yocto-dir/build/tmp-angstrom-glibc/sysroots/imx28scm
Reading symbols from yocto-dir/build/tmp-angstrom-glibc/sysroots/imx28scm/lib/ld-linux.so.3...done.
Loaded symbols for yocto-dir/build/tmp-angstrom-glibc/sysroots/imx28scm/lib/ld-linux.so.3
Cannot access memory at address 0x0
After setting the sysroot, it still does not give symbols.
(gdb) bt
#0 0x4ae90a20 in ?? ()
#1 0x00000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) b main
Breakpoint 1 at 0x84a8: file abc.c, line 5.
(gdb) c
Continuing.
Breakpoint 1, main () at abc.c:5
5 printf("Hello world\n");
Okay, when it hits a breakpoint, it does display symbols.
(gdb) bt
Cannot access memory at address 0x0
#0 main () at abc.c:5
However, it goes weird stepping beyond there.
(gdb) n
Cannot access memory at address 0x1
0x4aea6ea0 in ?? ()
(gdb) bt
#0 0x4aea6ea0 in ?? ()
#1 0x0000a014 in do_lookup_unique (Cannot access memory at address 0x1
undef_map=0x1, ref=0x0, strtab=0x56ebb27 <error: Cannot access memory at address 0x56ebb27>, sym=0x84a0 <main>, type_class=-1224757248, result=0x1, map=<optimized out>,
new_hash=<optimized out>, undef_name=<optimized out>) at /usr/src/debug/glibc/2.24-r0/git/elf/dl-lookup.c:332
#2 do_lookup_x (undef_name=<optimized out>, new_hash=<optimized out>, old_hash=<optimized out>, ref=0x0, result=<optimized out>, scope=0x177ff8e, i=<optimized out>, version=<optimized out>,
flags=-1224757248, skip=0x1, type_class=100, undef_map=0x1) at /usr/src/debug/glibc/2.24-r0/git/elf/dl-lookup.c:544
#3 0x4aec0b10 in ?? ()
Cannot access memory at address 0x1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
It can't find the proper version of libc.so.6.
(gdb) info sharedlibrary
warning: .dynamic section for "yocto-dir/build/tmp-angstrom-glibc/sysroots/imx28scm/lib/libc.so.6" is not at the expected address (wrong library or version mismatch?)
From To Syms Read Shared Object Library
0x000007d0 0x0001bee0 Yes yocto-dir/build/tmp-angstrom-glibc/sysroots/imx28scm/lib/ld-linux.so.3
0x4aee73c0 0x4afe2018 No yocto-dir/build/tmp-angstrom-glibc/sysroots/imx28scm/lib/libc.so.6
(gdb) n
Cannot find bounds of current function
It does not give an ideal debugging experience.
There is a gcc inside yocto-dir sysroot (as used above), as well as in /usr/local/oecore-x86_64. They both behave the same. The /usr/local/oecore-x86_64 SDK is freshly built and installed.
Similarly, there is an imx28scm sysroot inside yocto-dir (as used above), as well as in /usr/local/oecore-x86_64, and they both behave the same. However, they clearly do have different versions of libc.so.6 - yocto-dir's is 14.8MB, and /usr/local/oecore-x86_64's is 1.3MB. This is a concern, however setting either of these locations as the sysroot does not fix the problem.
One workaround is to link with -static. GDB does give symbols in this case:
(gdb) target remote DEVICE-IP:2345
Remote debugging using DEVICE-IP:2345
_start () at ../sysdeps/arm/start.S:79
79 ../sysdeps/arm/start.S: No such file or directory.
(gdb) set sysroot yocto-dir/build/tmp-angstrom-glibc/sysroots/imx28scm
(gdb) bt
#0 _start () at ../sysdeps/arm/start.S:79
(gdb) b main
Breakpoint 1 at 0x8480: file abc.c, line 5.
(gdb) c
Continuing.
Breakpoint 1, main () at abc.c:5
5 printf("Hello world\n");
(gdb) n
6 return 0;
(gdb) n
7 }
Linking with -Wl,--verbose seems to show it is linking with the library in the expected sysroot:
yocto-dir/build/tmp-angstrom-glibc/sysroots/x86_64-linux/usr/libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/6.2.1/ld: Attempt to open yocto-dir/build/tmp-angstrom-glibc/sysroots/imx28scm/lib/libc.so.6 succeeded
The linker also finds this one, but it isn't referred to as libc.so.6, so presumably this is not interfering.
yocto-dir/build/tmp-angstrom-glibc/sysroots/x86_64-linux/usr/libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/6.2.1/ld: Attempt to open yocto-dir/build/tmp-angstrom-glibc/sysroots/imx28scm/usr/lib/libc.so succeeded
Why is there a library version mismatch in this case? How can I get GDB to display symbols from the library which it expects? I do not wish to link statically.
Please make sure the libc in the box is same as the one in your build server.
sorry, this should be a comments, but currently, I don't have enough reputation.
Apparently GDB for ARM target has trouble with trying to load symbols before main() (Debugging shared libraries with gdbserver):
The problem I had was that gdbserver stops at the dynamic loader, before main, and the dynamic libraries are not yet loaded at that point, and so GDB does not know where the symbols will go in memory yet.
GDB appears to have some mechanisms to automatically load shared library symbols, and if I compile for host, and run gdbserver locally, running to main is not needed. But on the ARM target, that is the most reliable thing to do.
Therefore, set it to load shared symbols after main has been hit:
> b main
> c
<breakpoint hit>
> set sysroot <sysroot>
Or reload the symbols after you hit main.
> set sysroot <sysroot>
...
> b main
> c
<breakpoint hit>
> nosharedlibrary
> sharedlibrary
Or it might be useful in interfacing with IDE debuggers to set auto loading of symbols to be off on GDB startup:
> set auto-solib-add off

GDB quits when running the 'finish' command

I downloaded mingw-w64 so I can work on writing programs and debugging them from my home laptop, but for whatever reason, when ever I'm debugging a program with gdb and I wish to exit function using 'finish' command, gdb simply runs until it returns from function and simply exits and I return to the shell's prompt. I have no idea what is causing this bug, and it is especially annoying and make debugging very hard because it forces me to go through every line in a function before exiting (God forbids there's a loop). Has someone encountered this bug before? Is there a solution?
PS C:\Users\gamef\OneDrive\Desktop\CPE453\program4_tinyfs> gdb .\a.exe
GNU gdb (GDB) 8.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. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from .\a.exe...done.
(gdb) br writeData
Breakpoint 1 at 0x402e44: file TinyFS.c, line 299.
(gdb) run
Starting program: C:\Users\gamef\OneDrive\Desktop\CPE453\program4_tinyfs\a.exe
[New Thread 40396.0x1cc8]
[New Thread 40396.0x6e30]
[New Thread 40396.0x3090]
[New Thread 40396.0x9e38]
Thread 1 hit Breakpoint 1, writeData (begBlock=0, data=0x61fab2 "\001_", 'ÿ' <repeats 31 times>, size=254,
type=DIRECTORY) at TinyFS.c:299
299 Byte buff[BLOCKSIZE] = {0};
(gdb) s
300 buff[MAGIC_OFFSET] = MAGIC_NUMBER;
(gdb) finish
Run till exit from #0 writeData (begBlock=0, data=0x61fab2 "\001_", 'ÿ' <repeats 31 times>, size=254, type=DIRECTORY)
at TinyFS.c:300
PS C:\Users\gamef\OneDrive\Desktop\CPE453\program4_tinyfs>
It seems that this problem is a caused by a bug inside the 8.1 version of GDB. So I reverted back to GDB 8.0 which seems to work perfectly.

call to ffi_call fails even though arguments look right

Consider this gist. I have checked and double checked this piece of code for defects and can't find any apparent flaws in the code. It also compiles fine when I use g++ -g -std=c++11 -Wall dynlibtest.cc -ldl -lffi -lstdc++ -odynlibtest && ./dynlibtest (the -ldl and -lffi switches are for the dynamic loading and FFI libraries, respectively).
However, when the highlighted line (l.96) executes it segfaults.
I have also tried pulling it through gdb, and after installing the libc debugging symbols it spits this message out when the ./dynlibtest bin segfaults:
(gdb) next
Program received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:157
157 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory.
Who can help me understand why this segfaults? Is it a bug of some kind or am I using one of the API's wrong?
For reference: the first part of the code calls gettimeofday directly to show that the code can indeed find it, and that even the args are correct when it is called directly.
EDIT: I have added the gdb output when the code segfaults with the output of bt also attached:
$ gdb ./dynlibtest
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 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. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./dynlibtest...done.
(gdb) break 96
Breakpoint 1 at 0x401032: file dynlibtest.cc, line 96.
(gdb) run
Starting program: /home/j/dev/elisp-ffi/dynlibtest
Test started...
Got main program handle
pre-alloc: tv.tv_sec = 140737340592552
Sleeping for 1 second
post-alloc: tv.tv_sec = 1432058412
Sleeping for 1 second
Fn ptr call: tv.tv_sec = 1432058413
FFI CIF preparation is OK
Sleeping for 1 second
Breakpoint 1, main () at dynlibtest.cc:96
96 ffi_call(&cif, FFI_FN(gettimeofday), &result, args);
(gdb) next
Program received signal SIGSEGV, Segmentation fault.
__memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:157
157 ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such file or directory.
(gdb) bt
#0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:157
#1 0x00007ffff79d34c2 in memcpy (__len=8, __src=0x0, __dest=0x7fffffffda48) at /usr/include/x86_64-linux-gnu/bits/string3.h:51
#2 ffi_call (cif=0x7fffffffdca0, fn=0x400ab0 , rvalue=0x7fffffffdc40, avalue=0x7fffffffdc00) at ../src/x86/ffi64.c:504
#3 0x000000000040104e in main () at dynlibtest.cc:96
(gdb)

Resources