(0025098)
Alex Neundorf (developer)
2011-01-26 15:41

I think the patch needs a check whether CMAKE_C_COMPILER is the GNU compiler, I'm not sure for other compilers the switches are the same.

Alternatively, can you try to modify the original assembler file so that the warning goes away ?
There is not too much in it.
The .ident and .section lines at the end can be removed it seems.
Do you know what exactly is causing the problem ?
I could also generate an assembler file from a main() which doesn't call any function.

int main()
{
   int i=5;
   int j=17;
   return i*j;
}

Does this still cause the problem ?

Alex

(0025100)
Tomáš Chvátal (reporter)
2011-01-26 15:58

The issue is using glibc, particulary printf.
So if you wont link to any library it wont cause the problem and you can keep static assembler file :)

Tom

(0025113)
Alex Neundorf (developer)
2011-01-27 15:51

Does the attached main.s also show this problem ?
It calls now puts.
I guess the attached main2.s doesn't have this problem ?

Alex

(0025141)
Tomáš Chvátal (reporter)
2011-01-28 14:04

Thanks to help of guys on #gentoo-hardened i found out that the first main.s still produces texrel...
"/usr/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object."

main2.s for sure is clear of any texrel so it could be used in the test :)

Tom

(0025146)
Alex Neundorf (developer)
2011-01-28 15:02

Ok, I'll use main2.s then.

What is actually a DT_TEXTREL, what causes it and what is the problem with it ?

Alex

(0025147)
Tomáš Chvátal (reporter)
2011-01-28 15:10

Text relocation.
So relocation in text segment which contains executable code are not preffered.
Its quite possible, but text relocations actualy write into text segment it can pose as security risc.

http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml [^] <- this might be handy as it is nicely explained there :)

And thanks for the fix :)

Tom

(0025160)
Alex Neundorf (developer)
2011-01-29 12:45

Hmm, actually I'd like to keep a test program which prints something, so I see it really succeeded.
The assembler file attached here https://bugs.gentoo.org/338627 [^] has much more code...
Is it i686 specific, i.e. does it work also on i386 ?
__stack_chk_fail_local is a quite new feature, right ?
Can you generate an assembler file on Gentoo which doesn't have this ?

Thanks
Alex

(0025164)
Tomáš Chvátal (reporter)
2011-01-30 16:14

How about the attached assembly file (main3.S). Written by lovely people on our #gentoo-hardened channel. It works for hardened people and so should for you :)

Tom

(0025183)
Alex Neundorf (developer)
2011-01-31 16:09

Who or in which cases should the __PIC__ define be set ?

Alex

(0025185)
Tomáš Chvátal (reporter)
2011-01-31 16:31

fPIC should be defined on compiler line only when some specified arch require it (or like when hardening forces it). Usually one can mostly see it on DSOs.
Anyway given that it is platform independent code that is not to be enabled by default on x86 where this test run you probably don't need to be afraid that someone trigger it by accident.
If you want to see result for yourself on the fPIC enabled code just run "gcc -fPIC ..." (or is it -fpic? i am now not sure :P)

(0025417)
Alex Neundorf (developer)
2011-02-12 04:34

This will be fixed in 2.8.5.
In 2.8.5 the assembler support will move from "experimental" to its (I think) final state. Then the assembler test needs to work for more compilers, i.e. I'll do something with creating the assembler file on demand.

Alex

(0025740)
Alex Neundorf (developer)
2011-03-10 15:02

In next (which will become 2.8.5) the assembler file is now generated from the compiler. So the wartning should be gone.

Issue History
Date Modified	Username	Field	Change
2010-12-25 16:26	Tomáš Chvátal	New Issue
2010-12-25 16:26	Tomáš Chvátal	File Added: cmake-2.8.3-fix_assembler_test.patch
2010-12-27 10:36	Bill Hoffman	Assigned To	=> Alex Neundorf
2010-12-27 10:36	Bill Hoffman	Status	new => assigned
2011-01-26 15:41	Alex Neundorf	Note Added: 0025098
2011-01-26 15:58	Tomáš Chvátal	Note Added: 0025100
2011-01-27 15:29	Alex Neundorf	File Added: main.s
2011-01-27 15:50	Alex Neundorf	File Added: main2.s
2011-01-27 15:51	Alex Neundorf	Note Added: 0025113
2011-01-28 14:04	Tomáš Chvátal	Note Added: 0025141
2011-01-28 15:02	Alex Neundorf	Note Added: 0025146
2011-01-28 15:10	Tomáš Chvátal	Note Added: 0025147
2011-01-29 12:45	Alex Neundorf	Note Added: 0025160
2011-01-30 16:13	Tomáš Chvátal	File Added: main3.S
2011-01-30 16:14	Tomáš Chvátal	Note Added: 0025164
2011-01-31 16:09	Alex Neundorf	Note Added: 0025183
2011-01-31 16:31	Tomáš Chvátal	Note Added: 0025185
2011-02-12 04:34	Alex Neundorf	Note Added: 0025417
2011-03-10 15:02	Alex Neundorf	Note Added: 0025740
2011-03-10 15:02	Alex Neundorf	Status	assigned => closed
2011-03-10 15:02	Alex Neundorf	Resolution	open => fixed

Notes
(0025098) Alex Neundorf (developer) 2011-01-26 15:41	I think the patch needs a check whether CMAKE_C_COMPILER is the GNU compiler, I'm not sure for other compilers the switches are the same. Alternatively, can you try to modify the original assembler file so that the warning goes away ? There is not too much in it. The .ident and .section lines at the end can be removed it seems. Do you know what exactly is causing the problem ? I could also generate an assembler file from a main() which doesn't call any function. int main() { int i=5; int j=17; return i*j; } Does this still cause the problem ? Alex

(0025100) Tomáš Chvátal (reporter) 2011-01-26 15:58	The issue is using glibc, particulary printf. So if you wont link to any library it wont cause the problem and you can keep static assembler file :) Tom

(0025113) Alex Neundorf (developer) 2011-01-27 15:51	Does the attached main.s also show this problem ? It calls now puts. I guess the attached main2.s doesn't have this problem ? Alex

(0025141) Tomáš Chvátal (reporter) 2011-01-28 14:04	Thanks to help of guys on #gentoo-hardened i found out that the first main.s still produces texrel... "/usr/lib/gcc/i686-pc-linux-gnu/4.4.4/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object." main2.s for sure is clear of any texrel so it could be used in the test :) Tom

(0025146) Alex Neundorf (developer) 2011-01-28 15:02	Ok, I'll use main2.s then. What is actually a DT_TEXTREL, what causes it and what is the problem with it ? Alex

(0025147) Tomáš Chvátal (reporter) 2011-01-28 15:10	Text relocation. So relocation in text segment which contains executable code are not preffered. Its quite possible, but text relocations actualy write into text segment it can pose as security risc. http://www.gentoo.org/proj/en/hardened/pic-fix-guide.xml [^] <- this might be handy as it is nicely explained there :) And thanks for the fix :) Tom

(0025160) Alex Neundorf (developer) 2011-01-29 12:45	Hmm, actually I'd like to keep a test program which prints something, so I see it really succeeded. The assembler file attached here https://bugs.gentoo.org/338627 [^] has much more code... Is it i686 specific, i.e. does it work also on i386 ? __stack_chk_fail_local is a quite new feature, right ? Can you generate an assembler file on Gentoo which doesn't have this ? Thanks Alex

(0025164) Tomáš Chvátal (reporter) 2011-01-30 16:14	How about the attached assembly file (main3.S). Written by lovely people on our #gentoo-hardened channel. It works for hardened people and so should for you :) Tom

(0025183) Alex Neundorf (developer) 2011-01-31 16:09	Who or in which cases should the __PIC__ define be set ? Alex

(0025185) Tomáš Chvátal (reporter) 2011-01-31 16:31	fPIC should be defined on compiler line only when some specified arch require it (or like when hardening forces it). Usually one can mostly see it on DSOs. Anyway given that it is platform independent code that is not to be enabled by default on x86 where this test run you probably don't need to be afraid that someone trigger it by accident. If you want to see result for yourself on the fPIC enabled code just run "gcc -fPIC ..." (or is it -fpic? i am now not sure :P)

(0025417) Alex Neundorf (developer) 2011-02-12 04:34	This will be fixed in 2.8.5. In 2.8.5 the assembler support will move from "experimental" to its (I think) final state. Then the assembler test needs to work for more compilers, i.e. I'll do something with creating the assembler file on demand. Alex

(0025740) Alex Neundorf (developer) 2011-03-10 15:02	In next (which will become 2.8.5) the assembler file is now generated from the compiler. So the wartning should be gone.

Relationships