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: [PATCH v3 00/13] C99 variable length array support


Thanks for your review.

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf
> Of Joel Brobecker
> Sent: Wednesday, January 15, 2014 12:42 PM
> To: Agovic, Sanimir
> Cc: tromey@redhat.com; palves@redhat.com; xdje42@gmail.com; gdb-patches@sourceware.org;
> Boell, Keven
> Subject: Re: [PATCH v3 00/13] C99 variable length array support
> 
> Hello,
> 
> > this patch series (v3) add C99 variable length support to gdb.
> >
> > It allows the user to evaluate a vla like an ordinary static array e.g. print
> > its elements instead of printing the pointer to the array. In addition
> > the size of a vla can be retrieved with gdbs builtin sizeof operator.
> 
> We've started working internally at AdaCore on getting rid of some
> of the "GNAT encodings", with the goal of replacing them with pure
> dwarf constructs. One of the issues we've noticed is precisely
> the lack of support for dynamically-sized arrays, and I think
> this patch series would be a very good stepping stone towards that.
> 
It would be great if gnat could benefit from c99 and the upcoming fortran vla
support. I hacked on the D and go-lang compiler and could get variable length
arrays working without additional changes to gdb, simply by changing what the
compiler emits for ranges. 

> I remember I had one patch that made me a little nervous (patch #5/13,
> adding type re-fecthing after some value_* calls), but I also said
> that I would be OK if the patch went in as is. Apart from that,
> it seems to me that most/all? comments have been addressed?
> Perhaps, all we're missing is just v4 of the patch series?
> 
If it is OK for you I`d like to keep #5 as-is. AFAIK struct value
is opaque outside of its definition so any knowledge about how it works
(e.g. how values are constructed) means we leak implementation details.

> Any chance we could make progress on those? If there is anything
> I can do to assist, please let me know as well!
> 
Sure, I`m back and willing to address the missing parts =D

 -Sanimir


Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052


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