Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

2017-08-05 Thread Madalinski Piotr
Thanks LH_Mouse,

I've tested the -malign-data option and it does the job.

Sadly for now I'm stuck with gcc 4.9.2 in production and this option was 
introduced in 5.0.
Ah, well... At least the problem will solve itself in future, and the attribute 
approach must suffice for now.

Best regards,
Piotr Madaliński

-Original Message-
From: Liu Hao [mailto:lh_mo...@126.com]
Sent: 2 sierpnia 2017 17:54
To: mingw-w64-public@lists.sourceforge.net; Madalinski Piotr 
<piotr.madalin...@zf.com>
Subject: Re: [Mingw-w64-public] FW: Section sizes too big in object files 
(possible bug?)

On 2017/8/2 19:42, Madalinski Piotr wrote:
> Hi all,
>
> I'm having trouble with getting correct section sizes under MinGW.
> The example below demonstrates the issue:
>
> (... abridgement ...)
>
> 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?
>

`-malign-data=abi` shall fix the problem by minimizing the alignment
requirement:

```plaintext
E:\Desktop>gcc test.c -Wl,-s && objdump -h a.exe | grep -F test_sec
grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
   2 test_sec  0040  00404000  00404000  1c00  2**5

E:\Desktop>gcc test.c -Wl,-s -malign-data=abi && objdump -h a.exe | grep -F 
test_sec
grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
   2 test_sec  0024  00404000  00404000  1c00  2**2

```

Reference:
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/x86-Options.html#x86-Options

--
Best regards,
LH_Mouse

TRW Polska Sp. z o.o., ul. Rolnicza 33, 42-200 Czestochowa,
Sad Rejonowy w Czestochowie, KRS nr 077409
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. 077409,
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


Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

2017-08-05 Thread Madalinski Piotr
> and you get the following from objdump:
>[ 20](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x
>test_struct
>[ 21](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0024 a
>[ 22](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0028 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) 0x b
>[ 21](sec  7)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0004 a
>[ 22](sec  7)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0020
>test_struct

Well, yes, I suppose the location of variables in a single section is not 
deterministic.
But I'm using only one variable per section (actually I'm using -data-sections 
option),
and am arranging the sections in the linker script to create a memory region 
that can be mmaped form external file.

The linker script looks something like this:
 .mmaped_region BLOCK(__section_alignment__) : SUBALIGN(1)
 {
*(.test_section1)
*(.test_section2)
}
The problem is that by default test_section1 is too big because of the padding, 
and test_section2 ends up in the wrong place.

Best regards,
Piotr Madalinski.

TRW Polska Sp. z o.o., ul. Rolnicza 33, 42-200 Czestochowa,
Sad Rejonowy w Czestochowie, KRS nr 077409
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. 077409,
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


Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

2017-08-02 Thread Doug Semler
Ah, it was -malign-data, not -falign-data   no wonder I didn't find it.  DUH

-Original Message-
From: Liu Hao [mailto:lh_mo...@126.com] 
Sent: Wednesday, August 02, 2017 11:54 AM
To: mingw-w64-public@lists.sourceforge.net; Madalinski Piotr
<piotr.madalin...@zf.com>
Subject: Re: [Mingw-w64-public] FW: Section sizes too big in object files
(possible bug?)

On 2017/8/2 19:42, Madalinski Piotr wrote:
> Hi all,
> 
> I'm having trouble with getting correct section sizes under MinGW.
> The example below demonstrates the issue:
> 
> (... abridgement ...)
> 
> 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?
> 

`-malign-data=abi` shall fix the problem by minimizing the alignment
requirement:

```plaintext
E:\Desktop>gcc test.c -Wl,-s && objdump -h a.exe | grep -F test_sec
grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
   2 test_sec  0040  00404000  00404000  1c00  2**5

E:\Desktop>gcc test.c -Wl,-s -malign-data=abi && objdump -h a.exe | grep -F
test_sec
grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
   2 test_sec  0024  00404000  00404000  1c00  2**2

```

Reference: 
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/x86-Options.html#x86-Options

--
Best regards,
LH_Mouse



--
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


Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

2017-08-02 Thread Doug Semler
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) 0x
test_struct
[ 21](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0024 a
[ 22](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0028 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) 0x b
[ 21](sec  7)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0004 a
[ 22](sec  7)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0020
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 
#include 

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 077409 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. 077409, 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 b

Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

2017-08-02 Thread Liu Hao

On 2017/8/2 19:42, Madalinski Piotr wrote:

Hi all,

I'm having trouble with getting correct section sizes under MinGW.
The example below demonstrates the issue:

(... abridgement ...)

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?



`-malign-data=abi` shall fix the problem by minimizing the alignment 
requirement:


```plaintext
E:\Desktop>gcc test.c -Wl,-s && objdump -h a.exe | grep -F test_sec
grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
  2 test_sec  0040  00404000  00404000  1c00  2**5

E:\Desktop>gcc test.c -Wl,-s -malign-data=abi && objdump -h a.exe | grep 
-F test_sec

grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
  2 test_sec  0024  00404000  00404000  1c00  2**2

```

Reference: 
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/x86-Options.html#x86-Options


--
Best regards,
LH_Mouse


--
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


[Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

2017-08-02 Thread Madalinski Piotr
Hi all,

I'm having trouble with getting correct section sizes under MinGW.
The example below demonstrates the issue:

test.c:

#include 
#include 

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


TRW Polska Sp. z o.o., ul. Rolnicza 33, 42-200 Czestochowa,
Sad Rejonowy w Czestochowie, KRS nr 077409
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. 077409,
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