feat: Add basic CI/CD testing infrastructure (MVP)

[yc199911]

Overview

This PR introduces functional testing for mini-gdbstub, addressing issue #11 about limited CI/CD coverage. Building on @fabiomurer's CI infrastructure (format + compilation checks), this adds the missing functional testing layer.

Core Testing Framework

• Bash script (basic_test.sh) that automates the complete gdbstub testing workflow
• Cross-platform GDB detection - automatically chooses between riscv64-unknown-elf-gdb and gdb-multiarch
• Timeout protection - prevents CI hangs with configurable timeouts (30s for GDB operations)
• Process management - monitors emulator health and handles graceful cleanup
• Error detection - catches build failures, connection issues, and unexpected process termination

Testing Coverage

• GDB remote protocol connectivity (target remote 127.0.0.1:1234)
• Architecture setup verification (set architecture riscv:rv64)
• Register access functionality (info registers)
• Complete program execution flow (main → add function → program termination)
• Program completion detection via SIGTRAP signal

Implementation Details

The script follows a 5-stage testing pipeline:

1. Build verification - make build-emu with error detection
2. Server startup - launches gdbstub in background with PID tracking
3. Readiness check - waits for port 1234 with process health monitoring
4. Functional testing - executes GDB commands with timeout protection
5. Result validation - verifies expected output patterns in GDB logs

Test Results

The script successfully validates core gdbstub functionality:

bash
[INFO] Using GDB: gdb-multiarch
[INFO] ✓ GDB connection successful
[INFO] ✓ Program completed successfully

Questions for Maintainers

1. Direction validation: Does this testing approach align with the project's vision for CI/CD coverage?

2. Next steps: Should I focus on expanding test coverage (breakpoints, memory operations) or integrating with GitHub Actions first?

Fixes #11

[RinHizakura]

Please rebase your commits.

[RinHizakura]

I won't expect to build the project under the script, because this can make it inconvenient to check which step fails from the dashboard.

Please check .github/workflows/tests.yml. In fact, I already have one script to run some simple checks. Although it is quite simple, you can refer to this and merge these two for better coverage.

[RinHizakura]

Does this testing approach align with the project's vision for CI/CD coverage?

Looks good to me.

Should I focus on expanding test coverage (breakpoints, memory operations) or integrating with GitHub Actions first?

Integrating with GitHub Actions won't be a hard task. From my perspective, we just need to define an easy-to-use framework that can take the inputs:

1. GDB command sequence
2. Expected output

and validate the result. So that we can keep adding new GDB command sequences that we should check.