Recent changes regarding section type conflicts and #pragma clang section

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Recent changes regarding section type conflicts and #pragma clang section

Vassil Vassilev via cfe-dev

Hello Lucas,

 

We observe two issues regarding your commits “[Clang][Sema] Capturing section type conflicts between #pragma clang section”:

https://github.com/llvm/llvm-project/commit/0dac639f285a53dffe3239ec5561fa0fc2da0daf

https://github.com/llvm/llvm-project/commit/9d39df03a984ff4bed7d441a110d44976a8ab21b

 

A first observation is that once a section has been used as bss argument in a #pragma clang section, it is no longer possible to use this section in an explicit section annotation on a variable, even if this variable is zero-initialized:

https://godbolt.org/z/oiNHk3

 

[ In contrast, for a section used as the rodata argument, you *can* still do this, provided that the variable is “const”:

https://godbolt.org/z/wJvYiW ]

 

The problem for bss sections seems to be related to the newly introduced “PSF_ZeroInit” flag?

 

A second issue is that #pragma clang section provided a way to assign multiple variables to the same data section, mixing const, non-const and zero-initialized variables. When using an explicit section attribute, clang and gcc disallow to use the same section for const and non-const variables: https://godbolt.org/z/S76vKm (but you can mix zero-initialized and non-zero-initialized variables)

 

An implicit section annotation using #pragma clang section allowed to work around this, by specifying the same data section in the pragma:

 

              #pragma clang section data=”mydata” bss=”mydata” rodata=”mydata”

 

This is an example using clang-10: https://godbolt.org/z/vxty7T

 

This is now rejected, and granted, it was an abuse of the #pragma clang section. But is it not valid to assign both const and non-const variables to the same data section? Either with an explicit annotation or implicit?

 

Regards,

Bruno De Fraine

 


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Recent changes regarding section type conflicts and #pragma clang section

Vassil Vassilev via cfe-dev
Hello Bruno,

Thank you for bringing up those points.

On the first issue, clang indeed seems to be disregarding the initialization value of the variable when determining its section type.
The problem is related to the "PSF_ZeroInit" flag you mentioned. Clang is currently not taking the declaration's init value into consideration to flag its section as ZeroInit.
I'd need to take a deeper look into it to make sure it is safe to have the flag set in this scenario.
There are multiple ways to define sections - clang pragmas, attributes, ms pragmas, etc - and the interactions between them might be a bit unclear sometimes.

Regarding the mixing of different variable types into the same section, I'd say it might not be safe for all scenarios.
In fact, prior to those changes, clang was creating a single section when facing this, and defining the section type based only on the first variable declaration found after the pragma. Depending on the scatter file and target being used, this could cause RW variables to end up in RO memory.

Kind regards,
Lucas

From: Bruno De Fraine <[hidden email]>
Sent: Tuesday, June 9, 2020 1:05 PM
To: Lucas Prates <[hidden email]>
Cc: Jeroen Dobbelaere <[hidden email]>; clang Development List ([hidden email]) <[hidden email]>
Subject: Recent changes regarding section type conflicts and #pragma clang section
 

Hello Lucas,

 

We observe two issues regarding your commits “[Clang][Sema] Capturing section type conflicts between #pragma clang section”:

https://github.com/llvm/llvm-project/commit/0dac639f285a53dffe3239ec5561fa0fc2da0daf

https://github.com/llvm/llvm-project/commit/9d39df03a984ff4bed7d441a110d44976a8ab21b

 

A first observation is that once a section has been used as bss argument in a #pragma clang section, it is no longer possible to use this section in an explicit section annotation on a variable, even if this variable is zero-initialized:

https://godbolt.org/z/oiNHk3

 

[ In contrast, for a section used as the rodata argument, you *can* still do this, provided that the variable is “const”:

https://godbolt.org/z/wJvYiW ]

 

The problem for bss sections seems to be related to the newly introduced “PSF_ZeroInit” flag?

 

A second issue is that #pragma clang section provided a way to assign multiple variables to the same data section, mixing const, non-const and zero-initialized variables. When using an explicit section attribute, clang and gcc disallow to use the same section for const and non-const variables: https://godbolt.org/z/S76vKm (but you can mix zero-initialized and non-zero-initialized variables)

 

An implicit section annotation using #pragma clang section allowed to work around this, by specifying the same data section in the pragma:

 

              #pragma clang section data=”mydata” bss=”mydata” rodata=”mydata”

 

This is an example using clang-10: https://godbolt.org/z/vxty7T

 

This is now rejected, and granted, it was an abuse of the #pragma clang section. But is it not valid to assign both const and non-const variables to the same data section? Either with an explicit annotation or implicit?

 

Regards,

Bruno De Fraine

 


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev