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.
