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] |
Hello, Not too long ago, a customer submitted an example where an object that's quite complex was used, and GDB wasn't able to print its value. The object was an array of a variant record itself containing an array whose upper bound is determined at run time (by using a function call). The static debugging information is no longer sufficient to determine the actual object size, and the GNAT encoding actually already had something to say about this: -- The size of the objects typed as x should be obtained from the -- structure of x (and x___XVE, if applicable) as for ordinary types -- unless there is a variable named x___XVZ, which, if present, will -- hold the size (in bytes) of x. We just forgot to implement this in GDB. The attached patch does just that. Eventually, we want to see if we can use a pure-dwarf approach, and ditch the encoding at least on the platforms that support DWARF. Nico Roche has expressed some interest in this area, so if he ever has work days that are less than the current usual, I'm hopeful that we'll see some progress in that direction ;-). In the meantime, the patch is almost purely in the Ada section of the code. In fact, I could have put all the changes there, but I thought that there was one piece that really belonged in gdbtypes.c. Namely, when I discover an XVZ variable a compute the new size, I need to create a new type that's a copy of the original type, but with the length fixed. So I wrote a new routine called "copy_types". This function is the reason why I feel it's necessary for me to wait for feedback before committing. 2008-10-02 Joel brobecker <brobecker@adacore.com> * gdbtypes.c (copy_type): New function. * gdbtypes.h (copy_type): Add declaration. * ada-lang.c (ada_to_fixed_type_1): If there is a parallel XVZ variable, then use it. Tested on x86-linux. No regression. Any objection? Thanks, -- Joel
Attachment:
XVZ.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |