Studying note of GCC-3.4.6 source (14)

来源：互联网发布：为什么电脑连不到网络编辑：程序博客网时间：2024/05/08 00:58

2.2.3.1.5.2.2.5. Layout of UNION

Above line 854, rli->t is tree node of the type to be laid out., amd comes at here, field must be a FIELD_DECL. If rli->t is not a RECORD_TYPE, in C++, it must a node for a union. It has different layout policy than class and struct.

778 static void

779 place_union_field (record_layout_info rli, tree field) in stor-layout.c

780 {

781 update_alignment_for_field (rli, field, /*known_align=*/0);

782

783 DECL_FIELD_OFFSET (field) = size_zero_node;

784 DECL_FIELD_BIT_OFFSET (field) = bitsize_zero_node;

785 SET_DECL_OFFSET_ALIGN (field, BIGGEST_ALIGNMENT);

786

787 /* We assume the union's size will be a multiple of a byte so we don't

788 bother with BITPOS. */

789 if (TREE_CODE (rli->t) == UNION_TYPE)

790 rli->offset = size_binop (MAX_EXPR, rli->offset, DECL_SIZE_UNIT (field));

791 else if (TREE_CODE (rli->t) == QUAL_UNION_TYPE)

792 rli->offset = fold (build (COND_EXPR, sizetype,

793 DECL_QUALIFIER (field),

794 DECL_SIZE_UNIT (field), rli->offset));

795 }

Below update_alignment_for_field updates the variable alignment fields in rli, and return the alignment to give the field. Note that above at line 785, BIGGEST_ALIGNMENT, for x86 is 128.

686 static unsigned int

687 update_alignment_for_field (record_layout_info rli, tree field, in stor-layout.c

688 unsigned int known_align)

689 {

690 /* The alignment required for FIELD. */

691 unsigned int desired_align;

692 /* The type of this field. */

693 tree type = TREE_TYPE (field);

694 /* True if the field was explicitly aligned by the user. */

695 bool user_align;

696 bool is_bitfield;

697

698 /* Lay out the field so we know what alignment it needs. */

699 layout_decl (field, known_align);

2.2.3.1.5.2.2.5.1. Layout FIELD_DECL

We have seen layout_decl is invoked when creating node for declaration of variable, parameter and function return type. The function will set the size, mode and alignment of the node. However in build_decl, no FIELD_DECL will be laid out directly, it is delayed till now. Notice that known_align here is zero which means "as much alignment as you like".

352 void

353 layout_decl (tree decl, unsigned int known_align) in stor-layout.c

354 {

355 tree type = TREE_TYPE (decl);

356 enum tree_code code = TREE_CODE (decl);

357 rtx rtl = NULL_RTX;

358

359 if (code == CONST_DECL)

360 return;

361 else if (code != VAR_DECL && code != PARM_DECL && code != RESULT_DECL

362 && code != TYPE_DECL && code != FIELD_DECL)

363 abort ();

364

365 rtl = DECL_RTL_IF_SET (decl);

366

367 if (type == error_mark_node)

368 type = void_type_node;

369

370 /* Usually the size and mode come from the data type without change,

371 however, the front-end may set the explicit width of the field, so its

372 size may not be the same as the size of its type. This happens with

373 bitfields, of course (an `int' bitfield may be only 2 bits, say), but it

374 also happens with other fields. For example, the C++ front-end creates

375 zero-sized fields corresponding to empty base classes, and depends on

376 layout_type setting DECL_FIELD_BITPOS correctly for the field. Set the

377 size in bytes from the size in bits. If we have already set the mode,

378 don't set it again since we can be called twice for FIELD_DECLs. */

379

380 TREE_UNSIGNED (decl) = TREE_UNSIGNED (type);

381 if (DECL_MODE (decl) == VOIDmode)

382 DECL_MODE (decl) = TYPE_MODE (type);

383

384 if (DECL_SIZE (decl) == 0)

385 {

386 DECL_SIZE (decl) = TYPE_SIZE (type);

387 DECL_SIZE_UNIT (decl) = TYPE_SIZE_UNIT (type);

388 }

389 else if (DECL_SIZE_UNIT (decl) == 0)

390 DECL_SIZE_UNIT (decl)

391 = convert (sizetype, size_binop (CEIL_DIV_EXPR, DECL_SIZE (decl),

392 bitsize_unit_node));

The first part of the function just initializes certain fields of DECL node with associated TYPE node appropriately.

2.2.3.1.5.2.2.5.2. Treatment for Bit Field Decl

Below at line 402, DECL_BIT_FIELD returns nonzero, if the FIELD_DECL is for bit field.

layout_decl (continue)

394 if (code != FIELD_DECL)

395 /* For non-fields, update the alignment from the type. */

396 do_type_align (type, decl);

397 else

398 /* For fields, it's a bit more complicated... */

399 {

400 bool old_user_align = DECL_USER_ALIGN (decl);

401

402 if (DECL_BIT_FIELD (decl))

403 {

404 DECL_BIT_FIELD_TYPE (decl) = type;

405

406 /* A zero-length bit-field affects the alignment of the next

407 field. */

408 if (integer_zerop (DECL_SIZE (decl))

409 && ! DECL_PACKED (decl)

410 && ! (*targetm.ms_bitfield_layout_p) (DECL_FIELD_CONTEXT (decl)))

411 {

412 #ifdef PCC_BITFIELD_TYPE_MATTERS

413 if (PCC_BITFIELD_TYPE_MATTERS)

414 do_type_align (type, decl);

415 else

416 #endif

417 {

418 #ifdef EMPTY_FIELD_BOUNDARY

419 if (EMPTY_FIELD_BOUNDARY > DECL_ALIGN (decl))

420 {

421 DECL_ALIGN (decl) = EMPTY_FIELD_BOUNDARY;

422 DECL_USER_ALIGN (decl) = 0;

423 }

424 #endif

425 }

426 }

Among bit field declarations, there is special case of declaring size 0 (line 408). If fields are not required to be packed at bit boundary, it needs to further check the attribution of the aggregate type. Note that at line 410, DECL_FIELD_CONTEXT retrieves the node of UNION_TYPE or RECORD_TYPE containing the FIELD_DECL. Object targetm is target platform specified, for x86 system, the function pointer ms_bitfield_layout_p points to ix86_ms_bitfield_layout_p.

The explaination given in [2] is shown below:

This target hook returns true if bit-fields in the given RECORD_TYPE are to be laid out following the rules of Microsoft Visual C/C++, namely: (i) a bit-field won't share the same storage unit with the previous bit-field if their underlying types have different sizes, and the bit-field will be aligned to the highest alignment of the underlying types of itself and of the previous bit-field; (ii) a zero-sized bit-field will affect the alignment of the whole enclosing structure, even if it is unnamed; except that (iii) a zero-sized bit-field will be disregarded unless it follows another bit-field of nonzero size. If this hook returns true, other macros that control bit-field layout are ignored.

When a bit-field is inserted into a packed record, the whole size of the underlying type is used by one or more same-size adjacent bit-fields (that is, if its long:3, 32 bits is used in the record, and any additional adjacent long bit-fields are packed into the same chunk of 32 bits. However, if the size changes, a new field of that size is allocated). In an unpacked record, this is the same as using alignment, but not equivalent when packing.

If both MS bit-fields and `__attribute__((packed))' are used, the latter will take precedence. If `__attribute__((packed))' is used on a single field when MS bit-fields are in use, it will take precedence for that field, but the alignment of the rest of the structure may affect its placement.^[2]

15481 static bool

15482 ix86_ms_bitfield_layout_p (tree record_type) in i386.c

15483 {

15484 return (TARGET_USE_MS_BITFIELD_LAYOUT &&

15485 !lookup_attribute ("gcc_struct", TYPE_ATTRIBUTES (record_type)))

15486 || lookup_attribute ("ms_struct", TYPE_ATTRIBUTES (record_type));

15487 }

Above, TYPE_ATTRIBUTES fetches a TREE_LIST of IDENTIFIER nodes of the attributes that apply to the type. lookup_attribute iterates the TREE_LIST to find out the IDENTIFIER node of attr_name.

2733 tree

2734 lookup_attribute (const char *attr_name, tree list) in tree.c

2735 {

2736 tree l;

2737

2738 for (l = list; l; l = TREE_CHAIN (l))

2739 {

2740 if (TREE_CODE (TREE_PURPOSE (l)) != IDENTIFIER_NODE)

2741 abort ();

2742 if (is_attribute_p (attr_name, TREE_PURPOSE (l)))

2743 return l;

2744 }

2745

2746 return NULL_TREE;

2747 }

In GCC, the attribute name can be prefixed and postfixed with “__”, it is regarded as same as that without prefix and postfix. is_attribute_p recognizes attributes (attributes are defined by GNU C++, and supported by the compiler. Refer to [6] for the attributes available and the details).

2688 int

2689 is_attribute_p (const char *attr, tree ident) in tree.c

2690 {

2691 int ident_len, attr_len;

2692 const char *p;

2693

2694 if (TREE_CODE (ident) != IDENTIFIER_NODE)

2695 return 0;

2696

2697 if (strcmp (attr, IDENTIFIER_POINTER (ident)) == 0)

2698 return 1;

2699

2700 p = IDENTIFIER_POINTER (ident);

2701 ident_len = strlen (p);

2702 attr_len = strlen (attr);

2703

2704 /* If ATTR is `__text__', IDENT must be `text'; and vice versa. */

2705 if (attr[0] == '_')

2706 {

2707 if (attr[1] != '_'

2708 || attr[attr_len - 2] != '_'

2709 || attr[attr_len - 1] != '_')

2710 abort ();

2711 if (ident_len == attr_len - 4

2712 && strncmp (attr + 2, p, attr_len - 4) == 0)

2713 return 1;

2714 }

2715 else

2716 {

2717 if (ident_len == attr_len + 4

2718 && p[0] == '_' && p[1] == '_'

2719 && p[ident_len - 2] == '_' && p[ident_len - 1] == '_'

2720 && strncmp (attr, p + 2, attr_len) == 0)

2721 return 1;

2722 }

2723

2724 return 0;

2725 }

Back to ix86_ms_bitfield_layout_p, GCC supports two kinds layout of struct, one is adopted by MicroSoft (native), and the other used by GCC. TARGET_USE_MS_BITFIELD_LAYOUT is nonzero if using switch ms-bitfields (Table 7: target_switches for i386 system) which means using MS layout. ix86_ms_bitfield_layout_p returns nonzero if MS layout in used.

If GCC layout is required (not MS layout), PCC_BITFIELD_TYPE_MATTERS, at line 412, is 1 for x86 system. So alignment of bit-field unpacked and of zero size will be set with that of the type. For example, short i: 0, for GCC layout, the alignment will be 16 bits (same as short).

For PCC_BITFIELD_TYPE_MATTERS, the detail can be found in ^[2]as below.

[ Define this if you wish to imitate the way many other C compilers handle alignment of bit-fields and the structures that contain them.

The behavior is that the type written for a named bit-field (int, short, or other integer type) imposes an alignment for the entire structure, as if the structure really did contain an ordinary field of that type. In addition, the bit-field is placed within the structure so that it would fit within such a field, not crossing a boundary for it.

Thus, on most machines, a named bit-field whose type is written as int would not cross a four-byte boundary, and would force four-byte alignment for the whole structure. (The alignment used may not be four bytes; it is controlled by the other alignment parameters.) [Note: in below, we will see that the compiler will find the fittest integer type as the final type of the bit-filed]

An unnamed bit-field will not affect the alignment of the containing structure.

If the macro is defined, its definition should be a C expression; a nonzero value for the expression enables this behavior.

Note that if this macro is not defined, or its value is zero, some bit-fields may cross more than one alignment boundary. The compiler can support such references if there are `insv', `extv', and `extzv' insns that can directly reference memory.

The other known way of making bit-fields work is to define STRUCTURE_SIZE_BOUNDARY as large as BIGGEST_ALIGNMENT. Then every structure can be accessed with fullwords.

Unless the machine has bit-field instructions or you define STRUCTURE_SIZE_BOUNDARY that way, you must define PCC_BITFIELD_TYPE_MATTERS to have a nonzero value.

If your aim is to make GCC use the same conventions for laying out bit-fields as are used by another compiler, here is how to investigate what the other compiler does. Compile and run this program:

struct foo1 {

char x;

char :0;

char y;

};

struct foo2 {

char x;

int :0;

char y;

};

main () {

printf ("Size of foo1 is %d/n", sizeof (struct foo1));

printf ("Size of foo2 is %d/n", sizeof (struct foo2));

exit (0);

}

If this prints 2 and 5, then the compiler's behavior is what you would get from PCC_BITFIELD_TYPE_MATTERS.]

Following, for bit-field of nonzero size, the function tries to find out if certain integer mode can replace the bit field, for example, int j: 8; may be replaced by char j;. And note that only bit-filed of nonzero size will get handled.

layout_decl (continue)

428 /* See if we can use an ordinary integer mode for a bit-field.

429 Conditions are: a fixed size that is correct for another mode

430 and occupying a complete byte or bytes on proper boundary. */

431 if (TYPE_SIZE (type) != 0

432 && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST

433 && GET_MODE_CLASS (TYPE_MODE (type)) == MODE_INT)

434 {

435 enum machine_mode xmode

436 = mode_for_size_tree (DECL_SIZE (decl), MODE_INT, 1);

437

438 if (xmode != BLKmode

439 && (known_align == 0

440 || known_align >= GET_MODE_ALIGNMENT (xmode)))

441 {

442 DECL_ALIGN (decl) = MAX (GET_MODE_ALIGNMENT (xmode),

443 DECL_ALIGN (decl));

444 DECL_MODE (decl) = xmode;

445 DECL_BIT_FIELD (decl) = 0;

446 }

447 }

448

449 /* Turn off DECL_BIT_FIELD if we won't need it set. */

450 if (TYPE_MODE (type) == BLKmode && DECL_MODE (decl) == BLKmode

451 && known_align >= TYPE_ALIGN (type)

452 && DECL_ALIGN (decl) >= TYPE_ALIGN (type))

453 DECL_BIT_FIELD (decl) = 0;

454 }

At line 436, we have seen that mode_for_size_tree finds out the integer mode larger but most close to size of the declaration. Then GET_MODE_ALIGNMENT at line 440 just invokes get_mode_alignment.

299 unsigned int

300 get_mode_alignment (enum machine_mode mode) in stor-layout.c

301 {

302 return MIN (BIGGEST_ALIGNMENT, MAX (1, mode_base_align[mode]*BITS_PER_UNIT));

303 }

mode_base_align is the data generated by genmode according to machmode.def and i386-mode.def, it records the alignment of modes. Notice that VOID and BLK modes have alignment of 0.

BIGGEST_ALIGNMENT defines minimum size in bits of the largest boundary to which any and all fundamental data types supported by the hardware might need to be aligned. No data type wants to be aligned rounder than this. For x86 system, Pentium+ prefers DFmode values to be aligned to 64 bit boundary and Pentium Pro XFmode values at 128 bit boundaries.

However, this hides an important fact. It is that if the bit field is not of zero size, neither it can be replaced by certain integer mode, the DECL_ALIGN is unset here (0 as initialized in make_node). For RECORD_TYPE, this fact is crucial for bit field layout.

2.2.3.1.5.2.2.5.3. Treatment for Other Field Decl

Fields other than bit-field then are handled by following code snippet.

layout_decl (continue)

455 else if (DECL_PACKED (decl) && DECL_USER_ALIGN (decl))

456 /* Don't touch DECL_ALIGN. For other packed fields, go ahead and

457 round up; we'll reduce it again below. We want packing to

458 supersede USER_ALIGN inherited from the type, but defer to

459 alignment explicitly specified on the field decl. */;

460 else

461 do_type_align (type, decl);

Take declaration like below as example:

struct sdla_cmd {

char opp_flag __attribute__((packed));

char cmd __attribute__((packed));

short length __attribute__((packed));

char retval __attribute__((packed));

short dlci __attribute__((packed));

char flags __attribute__((packed));

short rxlost_int __attribute__((packed));

long rxlost_app __attribute__((packed));

char reserve[2] __attribute__((packed));

char data[SDLA_MAX_DATA] __attribute__((packed)); /* transfer data buffer */

} __attribute__((aligned (2)));

For above declared fields, DECL_PACKED will be set, and DECL_USER_ALIGN is also set because the struct containing them is declared as aligned at boundary 2. For such case, we leave DECL_ALIGN to be handled below.

For other declarations, do_type_align updates the alignment attributions for declarations according to associated types, which also comes from mode_base_align

2.2.3.1.5.2.2.5.4. Further Adjustment

Next, further adjustment according to the target platform is expected.

layout_decl (continue)

463 /* If the field is of variable size, we can't misalign it since we

464 have no way to make a temporary to align the result. But this

465 isn't an issue if the decl is not addressable. Likewise if it

466 is of unknown size.

467

468 Note that do_type_align may set DECL_USER_ALIGN, so we need to

469 check old_user_align instead. */

470 if (DECL_PACKED (decl)

471 && !old_user_align

472 && (DECL_NONADDRESSABLE_P (decl)

473 || DECL_SIZE_UNIT (decl) == 0

474 || TREE_CODE (DECL_SIZE_UNIT (decl)) == INTEGER_CST))

475 DECL_ALIGN (decl) = MIN (DECL_ALIGN (decl), BITS_PER_UNIT);

476

477 /* Should this be controlled by DECL_USER_ALIGN, too? */

478 if (maximum_field_alignment != 0)

479 DECL_ALIGN (decl) = MIN (DECL_ALIGN (decl), maximum_field_alignment);

480 if (!DECL_USER_ALIGN (decl))

481 {

482 /* Some targets (i.e. i386, VMS) limit struct field alignment

483 to a lower boundary than alignment of variables unless

484 it was overridden by attribute aligned. */

485 #ifdef BIGGEST_FIELD_ALIGNMENT

486 DECL_ALIGN (decl)

487 = MIN (DECL_ALIGN (decl), (unsigned) BIGGEST_FIELD_ALIGNMENT);

488 #endif

489 #ifdef ADJUST_FIELD_ALIGN

490 DECL_ALIGN (decl) = ADJUST_FIELD_ALIGN (decl, DECL_ALIGN (decl));

491 #endif

492 }

493 }

For condition at line 470 & 471, indicates that if the field is packed but the alignment is not specified by “packed” attribute. And condition from line 472 to 474 indicates that, at the same time, if the field is either nonaddressable (for instance, bit-field), or its DECL_SIZE_UNIT is 0 (ECL_SIZE_UNIT is unset, seems impossible), or its DECL_SIZE_UNIT is integer constant; then it must ensure that its alignment is at least 1 byte (consider empty base class within this packed derived).

Above, at line 478, maximum_field_alignment is set by #pragma pack(N). See that this directive works at last for user.

At line 485 following, BIGGEST_FIELD_ALIGNMENT is used by libobjc. It is not defined here for C++ language.

Then at line 489, for x86 system, ADJUST_FIELD_ALIGN is defined as following. It and BIGGEST_FIELD_ALIGNMENT are exclusive.

843 #define ADJUST_FIELD_ALIGN(FIELD, COMPUTED) / in i386.h

844 x86_field_alignment (FIELD, COMPUTED)

845 #endif

x86_field_alignment does platform special adjustment. When coming here, the declaration of unpacked type has been set after the type, which in turn comes from machmode.def. The file is constructed for all platforms. For certain types, upon certain platform, finer adjustment is expected. For example, double type, machmode.def says the alignment is 8 bytes. But on 32 bits x86 system, unless special specified, only 4 bytes is enough.

15705 int

15706 x86_field_alignment (tree field, int computed) in i386.c

15707 {

15708 enum machine_mode mode;

15709 tree type = TREE_TYPE (field);

15710

15711 if (TARGET_64BIT || TARGET_ALIGN_DOUBLE)

15712 return computed;

15713 mode = TYPE_MODE (TREE_CODE (type) == ARRAY_TYPE

15714 ? get_inner_array_type (type) : type);

15715 if (mode == DFmode || mode == DCmode

15716 || GET_MODE_CLASS (mode) == MODE_INT

15717 || GET_MODE_CLASS (mode) == MODE_COMPLEX_INT)

15718 return MIN (32, computed);

15719 return computed;

15720 }

At line 15711, TARGET_64BIT holds for 64 bits chip. And if TARGET_ALIGN_DOUBLE holds, it indicates target switch “-malign-double” is in used (by default is closed), which makes double, long double and long long be placed at boundary of double, i.e. 8 bytes. Of course, for these cases, no further adjustment is required.

And at line 15714行, get_inner_array_type is used fetch the type of element of the array.

3827 tree

3828 get_inner_array_type (tree array) in tree.c

3829 {

3830 tree type = TREE_TYPE (array);

3831

3832 while (TREE_CODE (type) == ARRAY_TYPE)

3833 type = TREE_TYPE (type);

3834

3835 return type;

3836 }

Rest code of layout_decl handles variable size declaration. For example, GNU C++ supports local variable size array, for instance: int j = 5; char arrC[i]; however this extension is inapplicable to fields of class.

2.2.3.1.5.2.2.5.5. Update record_layout_info

Following, we need update the layout data into record_layout_info. In below, field holds data from layout_decl.

update_alignment_for_field (continue)

700 desired_align = DECL_ALIGN (field);

701 user_align = DECL_USER_ALIGN (field);

702

703 is_bitfield = (type != error_mark_node

704 && DECL_BIT_FIELD_TYPE (field)

705 && ! integer_zerop (TYPE_SIZE (type)));

706

707 /* Record must have at least as much alignment as any field.

708 Otherwise, the alignment of the field within the record is

709 meaningless. */

710 if (is_bitfield && (* targetm.ms_bitfield_layout_p) (rli->t))

711 {

712 /* Here, the alignment of the underlying type of a bitfield can

713 affect the alignment of a record; even a zero-sized field

714 can do this. The alignment should be to the alignment of

715 the type, except that for zero-size bitfields this only

716 applies if there was an immediately prior, nonzero-size

717 bitfield. (That's the way it is, experimentally.) */

718 if (!integer_zerop (DECL_SIZE (field))

719 ? ! DECL_PACKED (field)

720 : (rli->prev_field

721 && DECL_BIT_FIELD_TYPE (rli->prev_field)

722 && ! integer_zerop (DECL_SIZE (rli->prev_field))))

723 {

724 unsigned int type_align = TYPE_ALIGN (type);

725 type_align = MAX (type_align, desired_align);

726 if (maximum_field_alignment != 0)

727 type_align = MIN (type_align, maximum_field_alignment);

728 rli->record_align = MAX (rli->record_align, type_align);

729 rli->unpacked_align = MAX (rli->unpacked_align, TYPE_ALIGN (type));

730 }

731 }

732 #ifdef PCC_BITFIELD_TYPE_MATTERS

733 else if (is_bitfield && PCC_BITFIELD_TYPE_MATTERS)

734 {

735 /* Named bit-fields cause the entire structure to have the

736 alignment implied by their type. */

737 if (DECL_NAME (field) != 0)

738 {

739 unsigned int type_align = TYPE_ALIGN (type);

740

741 #ifdef ADJUST_FIELD_ALIGN

742 if (!TYPE_USER_ALIGN (type))

743 type_align = ADJUST_FIELD_ALIGN (field, type_align);

744 #endif

745

746 if (maximum_field_alignment != 0)

747 type_align = MIN (type_align, maximum_field_alignment);

748 else if (DECL_PACKED (field))

749 type_align = MIN (type_align, BITS_PER_UNIT);

750

751 /* The alignment of the record is increased to the maximum

752 of the current alignment, the alignment indicated on the

753 field (i.e., the alignment specified by an __aligned__

754 attribute), and the alignment indicated by the type of

755 the field. */

756 rli->record_align = MAX (rli->record_align, desired_align);

757 rli->record_align = MAX (rli->record_align, type_align);

758

759 if (warn_packed)

760 rli->unpacked_align = MAX (rli->unpacked_align, TYPE_ALIGN (type));

761 user_align |= TYPE_USER_ALIGN (type);

762 }

763 }

764 #endif

765 else

766 {

767 rli->record_align = MAX (rli->record_align, desired_align);

768 rli->unpacked_align = MAX (rli->unpacked_align, TYPE_ALIGN (type));

769 }

770

771 TYPE_USER_ALIGN (rli->t) |= user_align;

772

773 return desired_align;

774 }

At line 710 above, the condition tells that if it is MS struct layout and it is the bit-field declaration, then to enter block at line 724, it must be packed; or if it has zero size, and previous field is bit field of nonzero size. Notice that for GCC default bit field layout, only naming declaration should have impact upon the structure.

As we expect, the size of the union is determined by it biggest field. In place_union_field, rli->offset is set in this way.