Breakpoint not working in Simics 2021.24 if the target was compiled in a different machine - simics

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

Related

Issue debugging a 32-bits assembly Hello world with GDB on a Raspberry Pi running a 64 bit version of Linux

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

Unable to lo load symbols table and perform symbolic debugging with Simics

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.

Need some help in Fuzzing Mosquitto lib

Here comes a bug while fuzzing Mosquitto lib, I would like to know the solution.
Step1. compile the lib
#:~/fuzz/fuzzmqtt/mosquitto$ ls
about.html doc Makefile security
aclfile.example docker man SECURITY.md
appveyor.yml edl-v10 misc service
buildtest.py epl-v10 mosquitto.conf set-version.sh
ChangeLog.txt examples Mosquitto.podspec snap
client installer notice.html src
CMakeLists.txt lib pskfile.example test
compiling.txt libmosquitto.pc.in pwfile.example THANKS.txt
config.h libmosquittopp.pc.in readme.md travis-configure.sh
config.mk LICENSE.txt readme-tests.md travis-install.sh
CONTRIBUTING.md logo readme-windows.txt www
#:~/fuzz/fuzzmqtt/mosquitto$ sudo make install CC="clang -O2 -fno-omit-frame-pointer -g -fsanitize=address -fsanitize-coverage=trace-pc-guard,trace-cmp,trace-gep,trace-div" -j2
Step2. compile the fuzzer
#:~/fuzz/fuzzmqtt/mosquitto/lib$ clang -g -O1 -fsanitize=fuzzer,address mos_fuzzer.cc -o mos_fuzzer -lmosquitto
Step3. Run the fuzzer and got the bug
#~/fuzz/fuzzmqtt/mosquitto/lib$ ./mos_fuzzer
INFO: Seed: 106983829
INFO: Loaded 1 modules (2337 guards): 2337 [0x7f157cd816b0, 0x7f157cd83b34),
INFO: Loaded 1 modules (1 inline 8-bit counters): 1 [0x787f80, 0x787f81),
INFO: Loaded 1 PC tables (1 PCs): 1 [0x565af8,0x565b08),
ERROR: The size of coverage PC tables does not match the
number of instrumented PCs. This might be a compiler bug,
please contact the libFuzzer developers.
Also check https://bugs.llvm.org/show_bug.cgi?id=34636
for possible workarounds (tl;dr: don't use the old GNU ld)
The code is as follow
#include "stdio.h"
#include "mosquitto.h"
#include "assert.h"
#include "stdint.h"
#include "stddef.h"
extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
bool clean_session = true;
struct mosquitto *mosq = NULL;
mosquitto_lib_init();
void *data_1=(void *)data;
mosq = mosquitto_new(NULL, clean_session, data_1);
mosquitto_destroy(mosq);
mosquitto_lib_cleanup();
return 0;
}
Thank you

SIGSEGV on memory access in Beaglebone Black (ARM) cross-compilation w/ Eclipse - Linaro

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.

How to Debug MobileSubstrate Tweaks?

What is the best way to debug MobileSubstrate extensions, i.e. placing breakpoints etc.? Is there away to do this in Xcode? GNU Debugger?
I use the syslog and tail. You'll need syslogd and Erica Utilities from Cydia. Then throughout your tweak place NSLog(#"breakpoint 1 - %#", someObject); and run the tweak.
tail -f /var/log/syslog
#define Debugger() { kill( getpid(), SIGINT ) ; }
Then you just call Debugger() wherever you want to place a breakpoint.
You can also raise an exception if you want to trace the stack:
[NSException raise:#"Exception Message" format:formatString];
Mobilesubstrate injects your dylib into the target process. Debugging the target process using GDB or LLDB is also debugging your extension code.
I will show you how to debug Mobilesubstrate extension using GDB.
Here is simple Mobilesubstrate/Logos extension:
%hook SBApplicationController
-(void)uninstallApplication:(id)application {
int i = 5;
i = i +7;
NSLog(#"Hey, we're hooking uninstallApplication: and number: %d", i);
%orig; // Call the original implementation of this method
return;
}
%end
I compile and install the code, and then attaching gdb to it:
yaron-shanis-iPhone:~ root# ps aux | grep -i springboard
mobile 396 1.6 4.3 423920 21988 ?? Ss 2:19AM 0:05.23 /System/Library/CoreServices/SpringBoard.app/SpringBoard
root 488 0.0 0.1 273024 364 s000 S+ 2:22AM 0:00.01 grep -i springboard
yaron-shanis-iPhone:~ root# gdb -p 488
You can find your Mobilesubstrate extension with the command:
(gdb) info sharedlibrary
This command print a list of loaded modules, find your extension:
test-debug-substrate.dylib - 0x172c000 dyld Y Y /Library/MobileSubstrate/DynamicLibraries/test-debug-substrate.dylib at 0x172c000 (offset 0x172c000)
You can also find the address of Logos uninstallApplication hook:
(gdb) info functions uninstallApplication
Which outputs this:
0x0172cef0 _logos_method$_ungrouped$SBApplicationController$uninstallApplication$(SBApplicationController*, objc_selector*, objc_object*)
You can debug your uninstallApplication hook function with breakpoints and other gdb features:
(gdb) b *0x0172cef0+36
Where the offset 36 is the assembly opcode that adding of 7 to the i variable in uninstallApplication hook function. You can continue to debug your Mobilesubstrate extension from here as you wish.