This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [commit/Ada] General ada-valprint improvements


> I have an ancient branch where I took a stab at removing val_print.
> It's a reasonably large patch and still doesn't even compile:
> 
>  30 files changed, 262 insertions(+), 486 deletions(-)
> 
> It's quite a big job and due to the way that most languages wind up
> deferring to the C printer, I didn't see a nice way to do it
> incrementally.

I was afraid of that. For Ada, I have some hopes that I could
re-implement val_print on top of value_print if I split ada_value_print.
If that works out, and if we find we can transition all languages
that way, perhaps that'll simplify the transition.

While talking crazy-large cleanup projects, I have been having this idea
in the back of my mind that I'd like the value printing to be done
by a language-independent engine, with the language only providing
decorations and hints. This is still very vague, and will require
a lot of thinking before I can even start, but the triggering thought
is varobj: varobj is already a generic object printing engine where,
if you simplify a bit, the language only provides child access.
Ideally, couldn't we extend that API to do exactly what each
LANG-print.c does? For instance, the only difference between
C structs and Ada records could be sumarized as:
  - C uses curly braces, while Ada uses parentheses
  - Ada likes to see the names of the fields

So, if we could extract out the varobj engine, and then make varobj
one formatter, and CLI-valprint another formatter, it seems like
most of the valprint units such as ada-valprint could go away.

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]