If I remember correctly, the default alignment for structure starts on a 32
byte boundary, to help prevent data member misalignments with SSE type
instructions. What you are seeing is the result of padding. I add an
integer in the same section
__attribute__((section("test_section"))) test_struct_t test_struct;
__attribute__((section("test_section"))) int a;
__attribute__((section("test_section"))) int b;
, and you get the following from objdump:
[ 20](sec 4)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000
test_struct
[ 21](sec 4)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000024 a
[ 22](sec 4)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000028 b
With the section size of 0x40. In fact, when adding another copy of the
test structure after a, you will get the second one starting at
0x40, with a section size of 0x80. This is no optimization, by the way.
NOTE: this is without ANY optimization flags. If you compile with -O1, you
get
[ 20](sec 7)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000000 b
[ 21](sec 7)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000004 a
[ 22](sec 7)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000000020
test_struct
With a section size of 0x60 (section padded to the 32 byte boundary -- but
honestly I don't know why the padding is to the 64 byte boundary above in
the first case, and only the 32 byte boundary in the second case)
Adding another copy of the structure, can cause different padding, different
rearrangements, depending upon the options.
You can force the alignment of something to a particular boundary with
__attribute__((aligned(n))), but that does introduce the potential to cause
misalignment with structure members.
Please note the above offsets are just the result of the gcc -c command,
just the object file. Doesn't even address the linker relocations and other
such things in the final executable (because of optimizations of
variable/section removals, etc). But the flag for the ordering is
-fno-toplevel-reorder at the higher optimization levels. Note none of the
-falign flags actually will do anything with data sections, if I remember
correctly.
Honestly, if your linker scripts cannot handle alignments and padding
introduced by a compiler, I would say that your *linker* script has the
issue and needs to be written so that things are aligned kept aligned
properly. I would *never* assume section layout or alignments *especially*
on a windows system (e.g. assuming that because the variable b is defined
after a is a HUGE mistake, because obviously the compiler rearranged them).
(note, it's been a little since I have futzed with linker scripts, but I do
know that you can specify at least .ALIGN in sections, if not padding)
-----Original Message-----
From: Madalinski Piotr [mailto:piotr.madalin...@zf.com]
Sent: Wednesday, August 02, 2017 7:43 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: [Mingw-w64-public] FW: Section sizes too big in object files
(possible bug?)
Hi all,
I'm having trouble with getting correct section sizes under MinGW.
The example below demonstrates the issue:
test.c:
#include <stdio.h>
#include <stdint.h>
typedef struct
{
uint16_t a;
uint16_t b[16];
uint8_t c[2];
} test_struct_t;
__attribute__((section("test_section")))
test_struct_t test_struct;
int main(int argc, char** argv) {
printf("size:%x, sizeof(test_struct_t)); }
After compiling under MinGW [gcc.exe (Rev2, Built by MSYS2 project) 7.1.0]
the size reported by the program are 0x24 which is correct, however objdump
reports the section size to be 0x40 (which is a problem for my linker
script)
I did compile the same program under both Clang/Win32 and GCC/Linux and the
section has correct size of 0x24 in both cases.
Adding align(1) attribute to the data definition is a workaround, that fixes
the problem, but due to external factors I want to avoid adding it, if
possible.
This behavior looks as a bug to me, but I can't say for sure.
Anyhow - is there some other (than the align(1) attribute) approach that
this behavior can be changed? Compiler option maybe?
Pozdrawiam / Kind Regards
Piotr Madaliński
Software Engineer
ZF TRW
Active & Passive Safety Technology
TRW Polska, Czestochowa Engineering Center ul. Rolnicza 33, 42-200
Czestochowa / Poland Phone +48 34 343 4864
piotr.madalin...@zf.com<mailto:piotr.madalin...@zf.com>
TRW Polska Sp. z o.o., ul. Rolnicza 33, 42-200 Czestochowa, Sad Rejonowy w
Czestochowie, KRS nr 0000077409 NIP nr 573-010-52-34, kapital zakladowy:
79.581.975 PLN
TRW Polska Sp. z o.o. Rolnicza 33 Str., 42-200 Czestochowa, Poland District
Court for Czestochowa, KRS no. 0000077409, tax identification no. NIP
573-010-52-34, share capital: 79.581.975 PLN
Niniejsza wiadomosc moze zawierac informacje poufne oraz/lub prawnie
chronione, przeznaczone do wylacznego uzytku adresata. Jesli nie jestescie
Panstwo adresatem przesylki lub jesli otrzymaliscie ja Panstwo omylkowo,
prosimy o bezzwloczne skontaktowanie sie z nadawca i usuniecie tej
wiadomosci. Wszelkie kopiowanie, wykorzystanie lub rozpowszechnianie tej
wiadomosci czy tez zawartych w niej informacji przez osoby inne niz adresat
jest niedozwolone i moze spowodowac odpowiedzialnosc prawna.
This e-mail together with any attachments, may contain confidential and/or
privileged information. If you are not the intended recipient or have
received this e-mail in error, please notify the sender immediately and
delete this e-mail. Any unauthorized copying, disclosure or distribution of
the material in this e-mail or any attachments is strictly forbidden.
----------------------------------------------------------------------------
--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
