I checked in support for mergeinfo types, in r1365035 and r1365079, generating them as formatted strings to work around the issues mentioned below.
- Julian
I (Julian Foad) wrote:
> I've been trying to add GDB pretty-printing support for svn_mergeinfo_t and svn_mergeinfo_catalog_t. The framework I'm extending is in tools/dev/gdb-py/svndbg/printers.py, created by Hyrum in January, with instructions for use in tools/dev/gdb-py/README.
>
> Two problems so far in adding mergeinfo support:
>
> 1. I am telling GDB that svn_mergeinfo_catalog_t is a 'map' whose children are svn_mergeinfo_t, but it is printing the children using the pretty-printer for plain apr_hash_t (which doesn't know that their values are rangelists, and so can't display the rangelists).
>
> (gdb) p unmerged_to_source_mergeinfo_catalog
> $1 = mergeinfo_catalog[2 paths] = {[A_COPY/mu] = hash of 1 items = {[/A/mu] = ...}, [A_COPY/D] = hash of 1 items = {[/A/D] = ...}}
>
> This must be a problem with the way GDB interacts with user-supplied regex-matching code when pretty printers are looked up, (see 'class TypedefRegexCollectionPrettyPrinter' at the top of 'printers.py'). I'm not sure whether it's fixable.
>
> 2. Mergeinfo contains range lists, but these are declared as apr_array_header_t. If we define an 'svn_rangelist_t' type, then the svn_mergeinfo_t pretty-printer can be defines as a 'map' whose children are svn_rangelist_t, and leave GDB to print each child.
>
> I could easily but clumsily work around both of these issues by formatting the whole mergeinfo or mergeinfo-catalog as a string and returning that instead of a 'map' type. If I could find out how to convert a gdb.Value object to a string representation, that would also be useful in a work-around. (I've searched the Net and read about gdb.execute() and gdb.parse_and_eval(), but not found a way.)
>
> Any insights into this?
>
> The attached patch is for exploration; it has the limitation described under (1) above and assumes an svn_rangelist_t type is defined in the object code. If I get no better ideas, I'll probably commit a version that uses string representations throughout as a work-around.
Received on 2012-07-24 16:41:48 CEST