Tag Archives: gdb

Netbeans 8.x “Could not get children iterator” or “NULL VALUE RETURNED FOR CHILDREN”

If you’re getting messages like this when debugging and trying to look at variables, chances are you might be debugging some glib2 code. If you are, welcome to https://bugzilla.gnome.org/show_bug.cgi?id=749092

It’s easy enough to manually patch the file, and presto, working debug again. It’s been fixed in GDB, I was seeing this in Fedora 22, which is not _entirely_ up to date these days, but you tend to expect that plain old host debugging should be pretty stable. blog post because the netbeans error string doesn’t help you find that gdb bug. You need to run gdb on the command line to find the real error: Python Exception iter() returned non-iterator of type '_iterator':

Esoteric python of the day: * and **

I was hacking up a grotty (but neat!) python plugin for gdb last night, and ran into a quirk I didn’t really understand. I had a list of numbers, and was using struct to make a suitable memory buffer for gdb.selected_inferior().write_memory. Except, it wasn’t quite working….

import struct
q = [1,2,3,4]
x = struct.pack("<4H", q)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
struct.error: pack requires exactly 4 arguments

I wasn’t really expecting this, normally things “just work” and python “does the right thing” (Computer! Do as I want, not as I say!) StackOverflow gave me the gem of using the * operator.

import struct
q = [1,2,3,4]
struct.pack("<4H", *q)
'\x01\x00\x02\x00\x03\x00\x04\x00'

OK, well and good, but WTF?! Where did that come from? Turns out it’s not an operator per se, but part of the call syntax. So * turns a list into a string of positional arguments, and ** turns a dict into a set of keyword arguments, like so.

def gofish(where, when):
     print(where, when)
 
gofish("lake", "tomorrow")
('lake', 'tomorrow')
gofish({"where" : "a river", "when": "next weekend"})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: gofish() takes exactly 2 arguments (1 given)
gofish(**{"where" : "a river", "when": "next weekend"})
('a river', 'next weekend')

So there, a rather esoteric corner of python I’d never seen before.

arm-none-eabi-gdb with python support on linux (Fedora 17)

I’ve been using the GCC ARM Embedded toolchain for STM32 development on linux for a while now. It’s maintained by ARM, it’s available for linux, windows and osx, and it’s just a zip of binaries. Untar, add to your path, and you’re golden. With the new 4.7 release (2012q4) it includes some decent code size improvements, and is generally just a one stop shop for getting a toolchain.

However, the linux builds don’t have python support in GDB. This isn’t necessarily a bad thing, but people are starting to put together some nice tools that plugin to GDB that rely on python support. There’s some experimental SWV/SWO support, there’s some neat support for printf without printf and, what I’m trying to do, dump a lot of data buffers straight out of ram on the target device for analysis in python.

So, I tried building it myself. I first tried just downloading recent gdb sources and adding python support, after setting the target to arm-none-eabi. but….. that didn’t play well with openocd, so I went back to trying to build the G-A-E provided sources instead.

Here’s what I needed on Fedora 17 x64

  • libmpc-devel
  • expat-devel
  • ncurses-devel
  • python-devel
  • bison

This then replaces step 5 from the provided instructions…

$ cd [extracteddir]/src
[dir]/src$ tar -xf gdb.tar.gz
[dir]/src$ cd gdb
./configure --with-expat --with-python --target=arm-none-eabi
make -j5

That got me a working gdb with python support…

Using netbeans for STM32 development with stlink (texane)

So, You got a STM32 Discovery board hey? Good for you! They’re cheap, and highly functional, but this ain’t your grandmother’s Arduino.

Here’s a rough and ready howto for developing in netbeans, and getting source level debugging for that code.

Required pieces

GNU arm toolchain installed and working.

I use summon-arm-toolchain for this. To test that it’s working, you can try any of the following:

You want to make sure that you can successfully compile via make from the command line first. If you can’t compile with the raw tools, netbeans isn’t going to magically fix that for you.

texane/stlink

A confusing name, but so be it. stlink (the software tool) provides tools for flashing STM32 chips via ST/Link v1 and v2 hardware. It also provides a gdbserver for debugging those chips. Get it from github (Sorry, there’s no tagged releases or anything yet, though there really should be)

Netbeans

Duh, this post is covering that. You need the c/c++ plugin and the gdbserver plugin. Download it here. For reference, I’m using 7.1 at the moment.

Setting up the toolchain in netbeans

  1. Click Tools->Options->C/C++
  2. Click on “Add” and set up a new toolchain for arm development. See the screenshot below
    Netbeans add tools dialog for gnu-arm

    Netbeans add tools dialog for gnu-arm

  3. Import your project as a makefile based project from existing sources. You can get netbeans to actually do all the compiling and things for you, but I find it hard to share the project that way. Not everyone uses netbeans, but makefiles are pretty portable.
  4. Build your project
  5. Flash your binary to the target. You can actually do this anyway you want, but we’ll use stlink’s st-flash tool.
    $ arm-none-eabi-objcopy -O binary your_project.elf your_project.bin
    $ /path/to/stlink/flash/st-flash write your_project.bin 0x08000000
    

    Here’s a screenshot from my makefile. (You can set up run modes in netbeans to do this too, but that’s not the focus here)

    console log for make and upload via stlink

    make and upload via stlink

  6. Start stlink’s gdbserver.
    karlp@tera:~/src/stlink$ ./gdbserver/st-util 
    2012-05-03T20:44:56 INFO src/stlink-common.c: Loading device parameters....
    2012-05-03T20:44:56 INFO src/stlink-common.c: Device connected is: L1 Med-density device, id 0x10186416
    2012-05-03T20:44:56 INFO src/stlink-common.c: SRAM size: 0x4000 bytes (16 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 256 bytes
    Chip ID is 00000416, Core ID is  2ba01477.
    init watchpoints
    Listening at *:4242...
    
  7. Whew, ok, just about there. Now in netbeans, choose “Debug->Attach debugger”.
  8. Choose “gdbserver” and make sure you put in the right host and port, (normally localhost, and 4242) and make sure it’s set to debug your project.
    screenshot for netbeans gdbserver attach dialog

    gdbserver-attach

  9. MAKE SURE you have set at least one breakpoint first. Something in netbeans doesn’t like adding breakpoints while it’s running, and it doesn’t like pressing the pause button. (but see the footnotes)
  10. Profit…
    screenshot showing netbeans Source debugging STM32 via stlink gdbserver

    Source debugging STM32 via stlink gdbserver

  11. That’s it. If any of the steps are glossed over too much, mail me and I’ll try and update to clarify.

    Sidenote: If you didn’t set any breakpoints in netbeans first, or you pressed pause, or you double clicked in the gutter to add some breakpoints, and nothing happened, you’ve hit whatever weirdness is in the gdbserver plugin. This problem is reported with other stm32 gdbservers, so it doesn’t appear to be a problem with stlink, but with netbeans. You can wake up netbeans again with kill -INT $(pidof arm-none-eabi-gdb)
    Thanks to gsmcmullin on ##stm32 on irc.freenode.net for that gem.

    Update for netbeans 7.2: Apparently you now have to put “target localhost:4242” into the gdbserver box, not just “localhost:4242”.

netbeans debug gdbserver: “Invalid argument”

I was trying to do some remote debugging via gdbserver the other day, using netbeans. I knew I’d had this working before, but I kept getting a rather bizarre (to my mind) error dialog:

I could connect happily via gdb on the command line, and on a whim I tried a different project in netbeans, which worked as expected. A bit more thought, and some comparison in the project properties showed up what was missing, the name of the binary output built for this project. After filling it in again everything works just fine :)

(This is with Netbeans 7.0.1, we won’t get into why it didn’t detect from the Makefile what the binary output was, when it runs quite fine in the non-cross configuration)