section attribute producing invalid sized sections

section attribute producing invalid sized sections

[Noah W]

Please let me know if this forum is not appropriate for this question.
Thanks.

I am using __attribute__((section("section-name"))) to place some data into
a section, and using the __start_..., __stop_..., symbols to iterate over
the contents of the section.

When one struct is added to the section the __start_/__stop_ bounds are
correct (the section defined is the size of one struct). When more than one
struct is added the size of the section is larger than I believe it should
be.

Broken on: Gcc: x86_64-linux-gnu, gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
Note: this test works as expected on: i386-redhat-linux, gcc version 4.1.2
20070925 (Red Hat 4.1.2-33)

I have attached a small test that demonstrates this. The size of the struct
is 24 bytes. If I place 3 structs in to the section the size calculated by
the difference between __start_ and __stop_ is 88, 16 more than I would
expect.

#include <stdio.h>

struct dummy {
	int *x, *y, *z;
};

extern struct dummy __start_section_test[];
extern struct dummy __stop_section_test[];

int main(int argc, char **argv)
{
	unsigned long long start, stop;

	static struct dummy entry_A __attribute__((section("section_test")));
	static struct dummy entry_B __attribute__((section("section_test")));
	static struct dummy entry_C __attribute__((section("section_test")));

	start = (unsigned long long)__start_section_test;
	stop = (unsigned long long)__stop_section_test;

	printf("struct size=%llu, start=%llu, stop=%llu, diff=%llu\n",
		(unsigned long long)sizeof(struct dummy), start, stop, stop-start);
}

-- 
View this message in context: http://www.nabble.com/section-attribute-producing-invalid-sized-sections-tp20744085p20744085.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: section attribute producing invalid sized sections

[Brian Dessent]

Noah W wrote:

> I have attached a small test that demonstrates this. The size of the struct
> is 24 bytes. If I place 3 structs in to the section the size calculated by
> the difference between __start_ and __stop_ is 88, 16 more than I would
> expect.

The extra size is the padding added to keep each struct aligned to a 16-
byte boundary as required by the ABI.  You can easily see what's going 
on by looking at the assembly output that gcc produces with -S:

        .file   "tc.c"
        .section        section_test,"aw",@progbits
        .align 16
        .type   entry_C.1557, @object
        .size   entry_C.1557, 24
entry_C.1557:
        .zero   24
        .align 16
        .type   entry_B.1556, @object
        .size   entry_B.1556, 24
entry_B.1556:
        .zero   24
        .align 16
        .type   entry_A.1555, @object
        .size   entry_A.1555, 24
entry_A.1555:
        .zero   24
        .text
.globl main
        .type   main, @function
main:
        ; and so on...

(Note when visually inspecting the assembly output you can add -fno-
asynchronous-unwind-tables to remove a lot of the clutter, but obviously 
don't use that when compiling unless you know that it's safe.)

You can alter the default alignment if you want, e.g.

        static struct dummy entry_A __attribute__((section("section_test"), aligned(8)));
        static struct dummy entry_B __attribute__((section("section_test"), aligned(8)));
        static struct dummy entry_C __attribute__((section("section_test"), aligned(8)));

But that's probably not a great idea because the default alignment 
requirement is there to allow the use of sse2 vector instructions that 
require aligned operands.  By changing the alignment you either prevent 
the compiler from using those instructions (if their definition was in 
scope at the time) or worse, you risk a runtime illegal instruction 
fault if you pass their address to a function that isn't aware of their 
changed alignment and assumes it's safe to use vector instructions on 
them.

Brian

Re: section attribute producing invalid sized sections

[Noah W]

> You can alter the default alignment if you want, e.g.
...
> But that's probably not a great idea because the default alignment 
> requirement is there to allow the use of sse2 vector instructions that 
> require aligned operands.

Thanks for the hints at seeing the assembly that helps and quick reply. The
alignment error
was what I expected, but still expected correct behavior in C when iterating
over the section.

That is, 

struct dummy *start = __start_section_test[];
struct dummy *stop = __stop_section_test[]
struct dummy *iter = start;

I should be able to use iter++ to access the next element in the section. Am
I doing such operation correctly, or assuming a different behavior that only
worked by chance on another arch?

Thanks,
Noah

-- 
View this message in context: http://www.nabble.com/section-attribute-producing-invalid-sized-sections-tp20744085p20744424.html
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: section attribute producing invalid sized sections

[Brian Dessent]

[ please keep replies on the mailing list ]

jayhawk@soe.ucsc.edu wrote:

> Thanks for the hints at seeing the assembly that helps and quick reply. The alignment error
> was what I expected, but still expected correct behavior in C when iterating
> over the section.
> 
> That is,
> 
> struct dummy *start = __start_section_test[];
> struct dummy *stop = __stop_section_test[]
> struct dummy *iter = start;
> 
> I should be able to use iter++ to access the next element in the section. Am
> I doing such operation correctly, or assuming a different behavior that only
> worked by chance on another arch?

I don't think that's a valid assumption.  It would be valid if you
defined them as an array, but since they are defined as separate
discrete objects there's nothing that requires them to be laid out
contiguously (or in any particular order.)

In practice if you want this to work you'll have to ensure that their
size is always a multiple of their alignment, such as x86 where it's 12
and 4 respectively so it works by chance.

One method that might be more portable would be to leave the actual
structures themselves in their normal location and accumulate pointers
to them in your own section_test.  The size and natural alignment of a
pointer type ought to be the same practically everywhere (famous last
words) so you shouldn't encounter any padding.

Brian