Support for GDB

[filipe]

Hi,

I have added GDB support to Uzebox Emulator making it possible to debug/develop the games on the emulator.
It is still a work-in-progress, so wait for the code soon.

I made a video, you can see it already running:
http://www.youtube.com/watch?v=kwUKjlnKOis

* I know I can embedded the video here, but it is too small.

-Filipe Rinaldi.

[Jhysaun]

OMG This is going to be so helpful.




Great Job

>J

[D3thAdd3r]

I agree, this will be a big step forward for development.

[paul]

Great job, Filipe!

It wasn't too long ago that Uze was offering a beer to Chris if he completed this task. Maybe that offer's still going

[filipe]

Great job, Filipe!

It wasn't too long ago that Uze was offering a beer to Chris if he completed this task. Maybe that offer's still going

Good! Can I change by Coca-Cola ?
Tomorrow (when I got more time) I will post the patch, it is already worth to give a try.

-Filipe Rinaldi

[filipe]

Hi,

Here is the patch.

The patch contains...
For the emulator:

• The previous changes to Emulator's Makefile (thread: viewtopic.php?f=9&t=614)
• Created two new file and added some code to existing ones.
• Some minor changes to avoid warnings and indentations.

For the games (Currently, I just changed Arkanoid to test):

• Some fixes to build on Linux
• Removed -ffunction-sections from the CFLAGS, It mess with debug symbols.
• Added 'gdb-script.cfg'
• Changed fom dwarf-2 to stabs. There are some issues about dwarf-2 to debug assembly code.

Let's go...

• Download the patch and unzip it
• Get a clean copy of Uzebox from the branch rev-beta5:

  Code: Select all

  $ svn co http://uzebox.googlecode.com/svn/branches/rev-beta5 rep_rev5

• Go to the branch directory and apply the patch:

  Code: Select all

  $ patch -p1 -i ../patch_uzem_gdb_rev108.diff
  patching file demos/Arkanoid/default/gdb-script.cfg
  patching file demos/Arkanoid/default/Makefile
  patching file tools/emulator/avr8.cpp
  patching file tools/emulator/avr8.h
  patching file tools/emulator/gdbserver.cpp
  patching file tools/emulator/gdbserver.h
  patching file tools/emulator/makefile
  patching file tools/emulator/uzem.cpp
  

• Go to tools/emulator and type make to build the emulator
• Go to demos/Arkanoid/default and type make to build Arkanoid
• To start uzem in gdb debug mode, use the option -d. If you want, you can specify the port to connect with -t (default is 1284):

  Code: Select all

  $ ./uzem -d --nosound ../../demos/Arkanoid/default/Arkanoid.hex
  
  NOTE THIS IS AN EXPERIMENTAL BRANCH OF THE UZEBOX EMULATOR
  PLEASE SEE THE FORUM FOR MORE DETAILS:  http://uzebox.org/forums
  
  Loading Hex Image...
  Waiting on port 1284 for gdb client to connect...
  

• Open a new shell, go to demos/Arkanoid/deafult/ and start avr-gdb. I'm using the gdb-script.cgf file with the option -x to: connect to the Uzem, insert a breakpoint at main() and continue :

  Code: Select all

  $ avr-gdb -x gdb-script.cfg Arkanoid.elf
  GNU gdb (GDB) 7.0.1
  Copyright (C) 2009 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=i686-pc-linux-gnu --target=avr".
  For bug reporting instructions, please see:
  <http://www.gnu.org/software/gdb/bugs/>...
  Reading symbols from /home/filipe/projetos/Uzebox/UzemGdb/rep_rev5/demos/Arkanoid/default/Arkanoid.elf...done.
  0x00000000 in __vectors ()
  Breakpoint 1 at 0xe824: file ../Arkanoid.c, line 221.
  
  Breakpoint 1, main () at ../Arkanoid.c:221
  221     int main(){
  (gdb)
  

Important notes...

• Windows and Mac users:
  Again, I just tried it on Linux, maybe need some fix to Windows and Mac. I'm waiting your feedback
• GDB:
  When I started the tests, I got some problems about the gdb trying to read invalid addresses when asked to print variables defined in flash (PROGMEM). I figured out gdb was trying to read from SRAM using an address supposed to be in flash. Using PGM_VOID_P in functions that pass const char * solved the problem (an example is StartSong(const char *midiSong)) but other cases were more trick.I was using avr-gdb 6.4 from ubuntu packages then I tried GDB 7.0.1 and it works without any changes.
• Variables in flash:
  It's possible to read, but when trying to make an assignment, gdb try write in SRAM. To workaround this, use the gdb command set {type} addr = value.
  Example using the global variable const char strEnd2[] PROGMEM = "THAT WAS THE LAST LEVEL" declared in Arkanoid.c:

  Code: Select all

  (gdb) print strEnd2
  $3 = "THAT WAS THE LAST LEVEL"
  (gdb) print strEnd2[0]=64
  Cannot access memory at address 0x80a003
  (gdb) print &strEnd2
  $4 = (char (*)[24]) 0x80a003
  (gdb) set {char}0xa003 = 64
  (gdb) print strEnd2
  $5 = "@HAT WAS THE LAST LEVEL"

  Note: You must remove the SRAM offset from the address: 0x80a003
• The GDB code is based on the GPL simulavr project. Thanks simulavr!!!

Sorry about the big post, the idea is create an wiki page to document GDB support.

References...
Building avr-gdb: http://www.nongnu.org/avr-libc/user-man ... tools.html
GDB manual: http://sourceware.org/gdb/current/onlinedocs/gdb/
GDB commands cheat sheet: http://www.yolinux.com/TUTORIALS/GDB-Commands.html
SimulAVR: http://savannah.nongnu.org/projects/simulavr/

Update v2: The patch already contains the fix for "-march". Thanks Jhysaun!
Update v3: Added Paul's changes for Windows and removed fread() warnings. Thanks Paul!
Update: The code is already in the repository (branch beta 5, revision 109)

-Filipe Rinaldi

[Jhysaun]

I added a zip file to the google code page of rev-beta5 with this patch applied.



>J
EDIT: Also to have it compile under 64-bit linux, change line 24 in the makefile from:

CPPFLAGS = -march=i686

to

CPPFLAGS = -march=x86-64

[filipe]

Ok J, we can make it transparent using the option native by default. This will even get the best performance for the CPU being used, but will not work in different CPUs (I'm setting -mtune too).

Plus, to make the build system flexible when creating a generic binary to release, the user can specify the target CPU with the option ARCH=cpu-type.
E.g: make release ARCH=i686

Just remove the old hard-coded

CPPFLAGS = -march=i686

and add this:

Code: Select all

######################################
# Architecture
######################################
ifeq ($(ARCH),)
    ARCH := native
    MTUNE := -mtune=native
endif

######################################
# Global Flags
######################################
CPPFLAGS = -march=$(ARCH) $(MTUNE)

-Filipe

[uze6666]

Wow! That very cool Filipe, I've waited a long time for this! I won't have time to work on Uzebox stuff very much in January, so if you're interested, PM me a gmail account so I can add you to the project's contributor in google code. You could also commit the build patch you developed earlier.

Btw, since I'm not too familiar with the command line version, does the GDB GUI works too?? That would be the cream of the crop!

-Uze

[filipe]

I supposed it works with any GDB client for AVR. I'm not sure about stabs vs dwarf-2 and PROGMEM issues, but this is about how to generate the elf binary. I will try this week.

-Filipe