dwarf2read.c (dwarf2_attach_fields_to_type): Add comment.

Message ID yjt2siin69hx.fsf@ruffy.mtv.corp.google.com
State New, archived
Headers

Commit Message

Doug Evans Oct. 16, 2014, 8:32 p.m. UTC
  Hi.

This patch just adds a comment to dwarf2_attach_fields_to_type.

I have some python code that makes use of field ordering of static
class members, which the dwarf spec supports.

"5.5.1 Structure, Union and Class Type Entries
....
The members of a structure, union, or class are represented by debugging
information entries that are owned by the corresponding structure type,
union type, or class type entry and appear in the same order as the
corresponding declarations in the source program."

This comment documents this so that the reader knows there is an
explicit reason for preserving the order.

2014-10-16  Doug Evans  <dje@google.com>

	* dwarf2read.c (dwarf2_attach_fields_to_type): Add comment.
  

Patch

diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index eccd11a..c97e0da 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -12500,7 +12500,12 @@  dwarf2_attach_fields_to_type (struct field_info *fip, struct type *type,
 
   /* Copy the saved-up fields into the field vector.  Start from the head of
      the list, adding to the tail of the field array, so that they end up in
-     the same order in the array in which they were added to the list.  */
+     the same order in the array in which they were added to the list.
+
+     N.B. The DWARF spec says that member DIEs appear in the same order as in
+     the source program (DWARF4 Structure, Union, and Class Type Entries,
+     section 5.5.1.  Users (e.g. python code) may be relying on this rule.  */
+
   while (nfields-- > 0)
     {
       struct nextfield *fieldp;