Consolidate source files

[carlnorum]

If I don't have pysvd.py in the current working directory, I get errors when trying to use gdb_svd. I've solved this problem in two ways:

1. set PYTHONPATH in gdb's environment, so gdb_svd.py knows where to find pysvd.py.
2. change the sys.path.append('.') line in gdb_svd.py to point to the directory where pysvd.py is located.

Neither of these is really ideal - is consolidating both into a single source file the only way to solve the problem?

[carlnorum]

I have a braindead consolidation on my fork. I don't really like it, since it makes the code harder to edit. Is there a real python way to handle this problem?

Link: https://github.com/carlnorum/PyCortexMDebug/tree/consolidate

[bnahill]

What might be best would be to make a complete python module which will contain svd.py (currently pysvd.py). Put it in $SOME_DIR_IN_PYTHONPATH/cortexmdebug. Then it can be imported as

from cortexmdebug.svd import SVDFile

Other modules could come along later as well. I'm not sure then where to put the GDB script to source but I think the same directory just for ease of use. I'll have to defer playing around with this until my thesis is in a better condition but overall, this could use better organization to make it easy to integrate into a project. I think overall, this makes the GDB script easy enough to manage as long as you can find the path of gdb_svd.py. The SVD files themselves should be dealt with by the user since they can't be distributed by us anyways...

Any further thoughts on this? I'll otherwise try to make this a proper module.

[carlnorum]

In my case, I'd like to distribute the python scripts along with my project. It makes it easier for the other developers if they don't have to install anything special to make things work. Right now, that means I have the two python files stashed in an etc/ directory in the project folder. The top-level makefile has a gdb target that looks like this:

gdb: all
    $(VERBOSE)PYTHONPATH=etc $(GDB) $(BUILD)/$(AXF_NAME) -x etc/gdbdebug

etc/gdbdebug contains a gdb script to connect to the target over JTAG, load & flash the code, and also set up this SVD module.

As it stands, it works fine, but that PYTHONPATH=etc bugs me a bit. I was just wondering if there's a good way to squash that out without needing to hardcode a path into the script (as described by #2 in my original post).

I guess the best possible thing would be to look for pysvd.py in the same directory as gdb_svd.py if that's possible - I couldn't make that work, though.

[bnahill]

Hmmm, that folder could be anywhere as long as it's in the python path. Another option is to create a quick python file (svd_config.py or something like that) in your build directory (presumably where you're running this all from) which sets the pythonpath and includes whatever you need when you source it. It could also deal with loading the correct SVD file and whatnot as needed.

I think in general that I'd still like to make a module out of this but I think our objectives can both be reached with a solution as above.

[carlnorum]

The wrapper script is a good idea - I'll give that a try and see what happens.

[carlnorum]

I am bad at python, but I came up with this:

#!/usr/bin/env python

# this program gets sourced from one level up in the tree, so we
# need to append the right path to make import directives work
# as expected
import sys
sys.path.append('etc')

# then import and start the real gdb/svd program
from gdb_svd import LoadSVD

if __name__ == "__main__":
    LoadSVD()

[bnahill]

Your Python is fine. Since this would be part of your project (whatever you're doing with some Toshiba devices), you can probably also have it load the SVD file too. If the parse time is annoying, you can also pickle the object to a file to save some time. I don't know about the Toshiba ones but the STM32F4 devices have really beefy SVD files...

[carlnorum]

The "pickling" sounds like a very good idea... I'll think about that. This SVD file is about 450 KB.

[bnahill]

I've made a new branch which I think creates a better overall workflow, especially for once more components (trace, timers, etc.) are integrated: https://github.com/bnahill/PyCortexMDebug/tree/repack

I didn't update docs yet, so here's how I think it would be used.

1. Install the package (python setup.py install)
2. Copy gdb.py from 'scripts' into your project's build directory (or wherever you debug from) -- or just source it from /usr/lib/python2.7/site-packages/cmdebug-0.1-py2.7.egg/scripts...
3. In GDB, 'source gdb.py' -- This will load basic GDB commands.
4. svd_load <wherever your SVD file is>

The package is named 'cmdebug' to keep it a bit simpler. As such, you can just 'from cmdebug.svd import SVDFile' if you just wanted to parse a file, for example.

What do you think of this?

[carlnorum]

Hi - sorry for the slow reply. That general idea looks good, but I haven't tried it out here yet.

[bnahill]

Being pretty busy, I'll just let it hang for a bit. It works fine for me this way but I probably won't get to that for a few days. If there are no conflicts mentioned, I'll merge it to master.

[carlnorum]

I'm trying to install this package into my target's gdb directory. print sys.path at the top level shows that /usr/local/lytro-arm/arm-none-eabi/share/gdb/python is part of the path, so I thought installing there would be good. I tried putting the egg right in there as well as in a cmdebug subdirectory, but I always get the same message:

  File "etc/gdb.py", line 23, in <module>
    from cmdebug.svd_gdb import LoadSVD
ImportError: No module named cmdebug.svd_gdb

I'm not doing anything crazy, right? This approach should work?

[carlnorum]

My bad - I just didn't install enough stuff. Trying again with (many) more flags.

[carlnorum]

:-( still can't get it to go. GDB won't open the egg or something? I'm sure I'm doing something wrong. If I copy the .py sources over there it works fine. I'm just running up against the limits of my "how-python-works" skills.

[bnahill]

Hey Carl, Installing it is a system-wide thing, done using python2 setup.py install. If you don't want to do that, just put the whole directory in your project and modify the gdb.py script to append the PyCortexMDebug directory (or equivalently the extracted egg file) to sys.path before it imports anything. Does this make sense?

[carlnorum]

Yeah - the system-wide one would work, I think, except I don't want to do that. I distribute the other tools for our project (cross compilers, libraries, etc) as a tarball, so I wanted to put this module in with that stuff.

I made it go by using:

export PYTHONPATH=/usr/local/lytro-arm/arm-none-eabi/share/gdb/python/cmdebug/
python setup.py install --install-lib=/usr/local/lytro-arm/arm-none-eabi/share/gdb/python/cmdebug --install-scripts=/usr/local/lytro-arm/arm-none-eabi/share/gdb/python/cmdebug

But for whatever reason, gdb still didn't find or couldn't use the egg, so I went in there and unzipped it and copied the .py & .pyc files into that directory.