I'm trying to debug my custom kernel under Simics preview 6.0.43.
I'm able to boot the kernel, set a breakpoint on a memory address and to have the execution hit the breakpoint.
Anyway I'm not able to load symbols for symbolic debugging.
This what I did:
simics> $disk0_image="/home/peppe/Scrivania/gpt.img"
simics>
simics> run-command-file /opt/simics/simics-qsp-x86-6.0.43/targets/qsp-x86/qsp-h
dd-boot.simics
simics> enable-debugger
Debugger enabled.
simics>
simics> add-symbol-file /home/peppe/Scrivania/g-os-grub2/g-os/kernel.bin
Context query * currently matches 6 contexts.
Symbol file added with id '1'.
simics> bp.source_location.break 0xc0000812
2: 0x2 (planted)
simics> bp.source_location.break kmain
3: 0x3 (not planted)
simics> list kamin.c
**At col 7: Cannot read symbol data. Invalid abbreviation table offset. Error reading DWARF data**
simics> run
running>
[tcf] Breakpoint 2 on execution in context mb.cpu0.core[0][0]
Now debugging the x86QSP1 board.mb.cpu0.core[0][0]
??()
push ebp
simics> board.mb.cpu0.core[0][0].pregs
rip = 0x00000000c0000812
I compiled my source with:
CFLAGS = -O0 -g -c -fno-builtin -m32
gcc version 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC)
My question: why the error message
At col 7: Cannot read symbol data. Invalid abbreviation table offset. Error reading DWARF data
that seems to prevent correct accessing to symbols?
Simics is supposed to support Dwarf 5 but you need to upgrade to at least 6.0.116, and 6.0.126 was released on March 9.
Related
I am trying to setup my Raspberry Pi so I can start learning ARM, and have issues debugging 32-bits ARM files. First, some informations maybe useful to my problem:
$ uname -a
Linux raspberrypi 5.15.32-v8+ #1538 SMP PREEMPT Thu Mar 31 19:40:39 BST 2022 aarch64 GNU/Linux
$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
I can write a hello world program (in assembly) for ARM64, compile it using as and ld, then execute it and debug it with gdb without any issue. For 32 bits ARM, after installing the package binutils-arm-linux-gnueabihf, I can compile my files using arm-linux-gnueabihf-as/ld and execute them without issue. However, I have problems debugging them with gdb.
My version of gdb is :
$ gdb -v
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
and I am using the GEF extension. The file command for the 32-bits file gives:
$ file helloworld
helloworld: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
After typing gdb helloworld, I can run it using the r command and it does print Hello world, but I can't debug it step by step: setting a breakpoint to the entry point (in my case, 0x10074 - obtained with info file -, which does not seem standard) makes the program run indefinitely, as if it was in an infinite loop, and stopping it with CTRL+C gives me:
$sp : 0x798fdfb4
$lr : 0xc6ac9670
$pc : 0x20
$cpsr: [negative ZERO CARRY OVERFLOW INTERRUPT FAST thumb]
────────────────────────────────────────────────────────────────────────────────────────── stack ────
[!] Unmapped address: '0x55798fdfb4'
─────────────────────────────────────────────────────────────────────────────────── code:arm:ARM ────
[!] Cannot disassemble from $PC
[!] Cannot access memory at address 0x20
──────────────────────────────────────────────────────────────────────────────────────── threads ────
[#0] Id 1, Name: "helloworld", stopped 0x20 in ?? (), reason: SIGINT
I am not sure what is going on. The address in Unmapped address: '0x55798fdfb4' looks like a standard .text address under PIE + ASLR, but I don't know why there would be mapping issues. How could I fix this ?
This answer is more an answer to the question: "How can I learn 32 bit assembly language on my raspberry Pi" than a direct answer to yours:
If your goal is to learn Aarch32 T32 or A32 assembly language on your raspberry Pi, I would strongly suggest to do so on a 32 bit distribution - I am not sure at this stage that you can debug a user mode Aarch32 program on an Aarch64 Linux system using an Aarch64 multiarch GDB or an Aarch32 version of GDB, my own attempts having been unsuccessful, and having not found to this day examples of how exactly to do this.
Another pro of this approach is that you will be able to concentrate on learning 32 bit Arm, and not asking yourself if your programs are not working because of a bug, or because off a potential problem/bug in the tools you are running on your Aarch64 system - my two cents.
If you have a spare 8GiB micro-SD card, you can install a 32 bit version of Ubuntu Server 22.04 from here.
One installed, here is what I am getting on my system:
cat /sys/firmware/devicetree/base/model
Raspberry Pi 3 Model B Rev 1.2
uname -a
Linux ubuntu 5.15.0-1005-raspi #5-Ubuntu SMP PREEMPT Mon Apr 4 12:25:49 UTC 2022 armv7l armv7l armv7l GNU/Linux
Install gcc and gdb:
sudo-apt -get install gcc gdb
Create hello-world.s, adapted from this example:
.arch armv7a
.file "hello-world.s"
.text
.global main
.syntax unified
.thumb
.thumb_func
.type main, %function
main:
mov r0, #1 # 1 = stdout
ldr r1, =hello_world # str pointer
mov r2, #13 # str len
mov r7, #4 # linux write syscall
svc 0 # software interrupt call write
exit:
mov r0, #0 # return code
mov r7, #1 # linux exit syscall
svc 0 # software interrupt call exit
.data
hello_world:
.ascii "Hello World!\n"
.end
as -g -o hello-world.o hello-world.s
gcc -g -o hello-world hello-world.o
./hello-world
Hello World!
GDB debug session:
gdb ./hello-world
GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
Copyright (C) 2022 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 "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://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 ./hello-world...
(gdb) b main
Breakpoint 1 at 0x4e0: file hello-world.s, line 10.
(gdb) run
Starting program: /home/ubuntu/hello-world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Breakpoint 1, main () at hello-world.s:10
10 mov r0, #1 # 1 = stdout
(gdb) step
11 ldr r1, =hello_world # str pointer
(gdb)
12 mov r2, #13 # str len
(gdb)
13 mov r7, #4 # linux write syscall
(gdb)
14 svc 0 # software interrupt call write
(gdb)
Hello World!
exit () at hello-world.s:16
16 mov r0, #0 # return code
(gdb)
17 mov r7, #1 # linux exit syscall
(gdb)
18 svc 0 # software interrupt call exit
(gdb)
[Inferior 1 (process 3043) exited normally]
(gdb) quit
I compiled a helloworld program in Ubuntu 20.04 LTS, I want to debug it in Simics, I set a breakpoint on main, but Simics won't break.
I tried compile it inside QSP-x86, that binary would work.
From my understanding, Simics could break on main no matter what the binary's original build environment was. I don't know why it doesn't break in my case.
Here is my steps:
step 1: compile helloworld in Ubuntu 20.04
$ cat a.c
#include <stdio.h>
int main()
{
printf("Hello world!\n");
return 0;
}
$ gcc -g a.c
step 2: copy a.out to Simics project root and upload it into QSP-x86 (firststeps.simics)
step 3:
simics> enable-debugger
simics> add-symbol-file a.out
simics> bp.source_location.break main
simics> run
running>
step 4: run a.out from the simulated serial console
Expected: the breakpoint on main should be triggered
But got: no breakpoint triggered at all
Looks like this is running inside a Linux process on the target. To debug software at the user level, you need to enable OS awareness so that the debugger can track when that particular software is running. ASLR should not matter for user-level processes when OS awareness is active, as the virtual addresses used by the code are the same in any case, even if the physical page is moved.
Some thing like:
simics> enable-tracker
simics> board.software.enable-tracker
simics> add-symbol-file prog.elf context-query = "name='prog.elf'"
simics> bp.source_location.break main context-query = "name='prog.elf'"
simics> bp.list
simics> bp.show <<bp number>>
simics> board.serconsole.con.input "prog.elf\n"
simics> r
...
This should stop when main runs in the program.
simics> bt
simics> list
Mandatory mark #IAmIntel
I tried to disable ASLR and run add-symbol-file with relocation-address, it works.
Simics:
simics> add-symbol-file pie-main.elf relocation-address = 0x555555554000
simics> bp.source_location.break main
Serial Console:
# echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
# ./pie-main
Ported assembly file from ARMCC syntax to GNU syntax. Throwing error while compilation.
Environment: GNU arm toolchain for ARM7 in Eclipse photon.
Requirement: Porting from keil ARMCC to GNU arm toolchain in eclipse.
Compiled and build properly. When I added an assembly file iap_blue.S(attached), facing compilation errors (Pasted below).
//iap_blue.S
.section .text,"x"
.balign 4
.globl blue_execute
blue_execute:
STMFD SP!,{LR} // Save Return Address
ADD R1,R0,#0x14 // R0 = &IAP.cmd, R1 = &IAP.stat
ADR LR,blue_exit // Return Address
LDR R2,=0x7FFFFFF1 // IAP Entry (Thumb Mode)
BX R2 // Execute IAP Command
blue_exit:
LDMFD SP!,{LR} // Restore Return Address
BX LR // Return
.end
12:18:38 **** Build of configuration Debug for project LEDblink ****
make all
Building file: ../LPC2468_startup.c
Invoking: GNU ARM Cross C Compiler
arm-none-eabi-gcc -mcpu=arm7tdmi-s -march=armv4t -marm -mthumb-interwork -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -include"E:\EclipseARM\workspace\LEDblink\iap_blue.S" -std=gnu11 -MMD -MP -MF"LPC2468_startup.d" -MT"LPC2468_startup.o" -c -o "LPC2468_startup.o" "../LPC2468_startup.c"
In file included from <command-line>:
E:\EclipseARM\workspace\LEDblink\iap_blue.S:1:13: error: expected identifier or '(' before '.' token
1 | .section .text,"x"
| ^
E:\EclipseARM\workspace\LEDblink\iap_blue.S:7:17: error: unknown type name 'ADD'
7 | ADD R1,R0,#0x14 // R0 = &IAP.cmd, R1 = &IAP.stat
| ^~~
E:\EclipseARM\workspace\LEDblink\iap_blue.S:7:31: error: stray '#' in program
7 | ADD R1,R0,#0x14 // R0 = &IAP.cmd, R1 = &IAP.stat
| ^
E:\EclipseARM\workspace\LEDblink\iap_blue.S:7:32: error: expected identifier or '(' before numeric constant
7 | ADD R1,R0,#0x14 // R0 = &IAP.cmd, R1 = &IAP.stat
| ^~~~
E:\EclipseARM\workspace\LEDblink\iap_blue.S:14:17: error: unknown type name 'BX'
14 | BX LR // Return
| ^~
E:\EclipseARM\workspace\LEDblink\iap_blue.S:15:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token
15 | .end
| ^
In file included from c:\program files (x86)\gnu tools arm embedded\9 2019-q4-major\arm-none-eabi\include\stdint.h:14,
from c:\program files (x86)\gnu tools arm embedded\9 2019-q4-major\lib\gcc\arm-none-eabi\9.2.1\include\stdint.h:9,
from ../LPC2468_startup.c:1:
c:\program files (x86)\gnu tools arm embedded\9 2019-q4-major\arm-none-eabi\include\sys\_stdint.h:20:9: error: unknown type name '__int8_t'
20 | typedef __int8_t int8_t ;
| ^~~~~~~~
subdir.mk:31: recipe for target 'LPC2468_startup.o' failed
make: *** [LPC2468_startup.o] Error 1
Thank you. Problem is solved.
I will like to elaborate on what was the mistake I was doing and how it is solved. This may be helpful for others.
Mistake 1:
I was using .s instead of .S for assembly file.
Mistake 2:
Included .S file in eclipse compiler include files as part of project settings.
Solution:
Checked C/C++ General --> File types which lists .S as assembly file. I changed .s to .S , mistake 1 is corrected.
Even though I was facing compilation errors which I have posted here.
I was not sure whether there is some eclipse-related issue or issue with my assembly file since I ported it to GNU syntax from ARMCC syntax.
I created my own make file and build the code using a command line, it builds successfully without any error. That means there was some issue with eclipse project configuration.
Then, I realized You don't have include assembly file in compiler settings. If You have already included it in the project. That alone will get the file to be recognized properly and assembled.
This solved the mistake2.
Thank you.
I am new to this, or better rusted (being 62).
Trying to develop on Beaglebone Black running Debian over IP using Eclipse Luna CDT and linaro tools.
I succeed in running and debugging standard helloworld.c.
Need to control GPIO fast (to connect to uncommon peripheral) but
all attempts to read or write to memory mapped registers fail.
Instruction
i = (*((volatile unsigned int *)(0x4804c130)))
which should read GPIO status register results in
Child terminated with signal = 0xb (SIGSEGV)
GDBserver exiting
logout
This is the source (hellobone.c) I compile without errors:
int main(void)
{
unsigned int i = 1;
i = (*((volatile unsigned int *)(0x4804c130))) ;
}
(I tried all variations on this pointer arithmetic)
Makefile trace: (ignore includes)
---COMPILE--- C:/hellobone/source/hellobone.c
"C:\gcc-linaro\bin\arm-linux-gnueabihf-gcc.exe" -c -o C:/hellobone/object/hellobone.o C:/hellobone/source/hellobone.c -marm -O0 -g -I. -IC:/hellobone/include
.
---LINK---
"C:\gcc-linaro\bin\arm-linux-gnueabihf-gcc.exe" -o hellobone C:/hellobone/object/hellobone.o C:/hellobone/object/tools.o C:/hellobone/object/gpio_v2.o -marm -O0 -g -I. -IC:/hellobone/include
.
The binary also crashes running as root from TTY:
root#beaglebone:~# ./hellobone
Segmentation fault
I installed Eclipse on the BBB Debian and read and write to memory works just fine. Just too slow compiling, and unstable, to be practical.
Reading memory should be doable. What am I doing wrong?
I suspect
GNU gdbserver (GDB) 7.4.1-debian
This gdbserver was configured as "arm-linux-gnueabihf"
But maybe I am missing something obvious, have not seen any post on this problem...
Really stuck. Being working on this for months now. Setting up toolchain very frustrating, nothing works as in YouTube videos..
Any help would be really appreciated
Marco
You need to mmap /dev/mem to access memory mapped peripherals through physical addresses. Easiest example / code I know does this goes by the name devmem2.
Thank you a lot, that certainly helped.
I compiled the program you gave me and it worked perfect in run mode in Eclipse, and in terminal on the remote machine.
Curiously, when running the Eclipse debugger, it crashes executing:
if((fd = open("/dev/mem", O_RDWR | O_SYNC)) == -1) FATAL;
I get this error message from gdbserver
Remote debugging from host 192.168.1.2
/root/hellobone: relocation error: /root/hellobone: symbol �pen, version GLIBC_2.4 not defined in file libc.so.6 with link time reference
Child exited with status 127
GDBserver exiting
Have been trying to use fopen but that gives a segmentation fault. Anyhow, I think that is a toolchain issue and not a programming issue.
I tried traditional ways and answers to analyze my .DMP files. WinDbg doesn`t take it, it outputs:
Could not find the C:\program files\softwaredir\dumps\dumpname_0313.rsa.dmp
File, Win32 error 0n87
It's an Multi Theft Auto: San Andreas crash dump. .rsa.dmp
Why doesn`t WinDbg take it, does it have to do with a certain dump type?
If anyone would want to try opening, here is the dumpfile with the issue
I would like to know if you have the solution to solve the opening problem/or any other tool to open the dump.
But I really need the exception that caused the crash, so either I'll need advise on how to open it or if I can fix it.
For case 2 (can't solve it for me here) the crash memory locations are:
Version 1.3.5-release 6078.0.000
Time Tue Jan 21 03:13:18 2014
Module C:\Program Files (x86)\MTA San Andreas 1.3\mods\deathmatch\client.dll
Code 0 x C0000005
Offset 0 x 0009E796
EAX 00000000 EBX 30994AB0 ECX 21E82218 EDX 0028F71C ESI 3098E520
EDI 6FBBCCC9 EBP 0028F7BC ESP 0028F6F4 EIP 1B00E796 FLG 00210246
CS 0023 DS 002B SS 002B ES 002B FS 0053 GS 002B
This is what I did to generate and analyze a dump file:
Downloaded ProcDump (a free Sysinternals tool)
Created a folder c:\dumps
Added ProcDump to PATH
Entered procdump -ma -i c:\dumps into command prompt to start the JustInTime debugger
Opened the dump file in visual studio
Using this method we were able to resolve a difficult bug and determine what exception was causing my machine to crash.