Re: [avr-gcc-list] GDB and avrmon-stk200

[Theodore Roth]

Hi Gopal,

On 7 Jul 2002, Gopal Santhanam wrote:

:) Hi,
:)
:) I have been trying to setup avrmon-stk200 with gcc & gdb.  Here are some
:) of my experiences along with a few questions.
:)
:) 1) Are there any plans to migrate avrmon-stk200 over to the gdb 5.2
:) infrastructure?  I understand there needs to be some significant changes
:) to make this happen.  I also see there is a push for development on the
:) AVaRICE alternative.  However, since AVR JTAG is only available on a few
:) AVR parts, it would still be very nice to have this low-cost,
:) quick-and-dirty SPI dongle debugging solution.

I've started the convertion to allow avr-mon to work with gdb 5.2. I think
I'm about a third of the way there. It is going slow since I can't work on
it at home in my free time yet. I might be able to spend some more time on
it today.

:)
:) 2) I am having some slight problems with the parallel port access.  If I
:) use uisp, I must rmmod parport_pc and reinstall it before I can use the
:) host's "mon" program.  Has anyone seen this before?  How is it possible
:) to reset the parallel port within the mon program?  Also, is there any
:) way I can easily use "mon" in user mode?  (I presume the only way is
:) setuid since the program uses the privileged function 'ioperm'.)

You are stuck with being root right now because of the use of ioperm. I
would bet that the parport_pc module is using the port when mon issues the
ioperm call and ioperm fails to get the resource. We should update the mon
to use parport devices from user space, then you could run mon as
non-root.

:)
:)
:) 3) I tried using the RPM distribution of avr-gcc-3.0.4,
:) avr-binutils-2.11.2-2, and avr-libc-20020203-4 from the Simulavr
:) homepage.  Using these tools to cross-compile the AVR code seems to
:) break the target monitor .  The stepping functionality was totally
:) hosed.  On the other hand, everything is okay when using gcc-3.0.2,
:) binutils-2.11.2, and avr-libc-20010821.  Some more investigation
:) suggests that this is an issue with the libc version!  I find that the
:) last libc revision that works is avr-libc-20011029

This doesn't surprise me as avr-mon is relatively old code and avr-libc
has gone through major changes lately (as have binutils/gcc/gdb ;-).

:)
:)
:) 4) When compiling gdb-4.18 with the avr patch, I only linked the opcodes
:) and bfd directories from the binutils source tree to the gdb source
:) tree.  I was unable to compile if I linked the include directory as is
:) stated in http://home.overta.ru/users/denisc/gdb/BUILD.avr-gdb.  As it
:) stands I see the same backtrace problem as quoted in
:)
:) http://avr.jpk.co.nz/pipermail/avr-gcc-list/2001-October/000859.html
:)
:) and I am unable to disassemble the program through gdb.  Both backtrace
:) and diassembly work in gdb 5.0 but there are other problems (see next
:) item).
:)
:)
:) 5) I figured out part of the register problems with gdb 5.0.  This was
:) first noted in the following post:
:)
:) http://avr.jpk.co.nz/pipermail/avr-gcc-list/2001-October/000860.html
:)
:) I see that the function monitor_supply_register is pickier in gdb 5.0
:) than in gdb 4.18.  It wants an '\n' or '\r' after each register in the
:) register dump.  I made a small fix in avrmon-stk200/host/mon.c to
:) reflect this.  However, things still aren't totally fixed.  When using
:) "info registers" in gdb, only a few of the registers are displayed.  GDB
:) prints the message "*value not available*" for most of the registers.
:) Any ideas?

Those are rather old versions of gdb. I found quite few buglets in the avr
patch when I ported it up to gdb-5.2. Once avr-mon is ported up to the
current tools, I would expect these problems to go away. ;-)

Ted Roth

avr-gcc-list at http://avr1.org