what does -fno-pic do ?
Hi, I am reading some OS kernel codes, and I find that in the Makefile used to build the kernel, there is a **-fno-pic** flag. I totally don't understand what that mean. I try to find some description from the man pages but can find no direct description about that flag(same for the **-fpic** flags). All I can find is something like: For Darwin, only the -m64 option also turns off the -fno-pic and -mdynamic-no-pic options. blah blah blah I try to google it but it seems that people rarely discuss it on the Web. Does the **pic** in that flag represent Programmable Interrupt Controller that is used by the kernel the control interrupts to CPU ? If it is, why no pic ? what does it really mean ? And, in addition, what would that flag influence the layout of the kernel image ? Thanks, Ruan.
Re: what does -fno-pic do
On 2016年07月11日 16:44, Mason wrote: On 10/07/2016 16:15, Yubin Ruan wrote: I am reading some OS kernel codes, and I find that in the Makefile used to build the kernel, there is a **-fno-pic** flag. I totally don't understand what that mean. I try to find some description from the man pages but can find no direct description about that flag (same for the **-fpic** flags). Really? A search for gcc fpic returns many relevant results. Here, pic stands for "position-independent code". The latest gcc documentation states: ( https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html ) -fpic Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC, 28k on AArch64 and 32k on the m68k and RS/6000. The x86 has no such limit.) Position-independent code requires special support, and therefore works only on certain machines. For the x86, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent. When this flag is set, the macros __pic__ and __PIC__ are defined to 1. Regards. I really search carefully in the man pages on my Ubuntu/Linux-14.04-LTS. I cannot find much description about that. Afterwards I find the online manual that you describe. Actually, I wonder why the man pages on my Ubuntu/Linux is so different from that online. Regards, Ruan.
Potential Bug in GCC5?
Hi,
I don't know whether this bug has been reported(I have check GCC Bugzillia
though) or has been resolved:
This program:
#include
int main()
{
char a = 'a';
printf("Size of char : %d\n",sizeof(a));
printf("Size of char : %d\n",sizeof('a'));
return 0;
}
when compiled with:
gcc -Wall testgcc.c -o testgcc -fexec-charset=utf-16
will triggers GCC's bug report reminder:
...
internal compiler error: character 0xa is not unibyte in execution character
set
...
Please submit a full bug report...
I think the problem comes with the "-fexec-character=utf-16" flag. And my GCC
version is (compiling with "gcc -v -Wall testgcc.c -o testgcc
-fexec-charset=utf-16")
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
COLLECT_GCC_OPTIONS='-fno-common' '-v' '-Wall' '-o' 'testgcc'
'-fexec-charset=utf-16' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/5/cc1 -quiet -v -imultiarch x86_64-linux-gnu
testgcc.c -quiet -dumpbase testgcc.c -mtune=generic -march=x86-64 -auxbase
testgcc -Wall -version -fno-common -fexec-charset=utf-16
-fstack-protector-strong -Wformat-security -o /tmp/ccVA6bpI.s
GNU C11 (Ubuntu 5.4.0-6ubuntu1~16.04.4) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/5/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C11 (Ubuntu 5.4.0-6ubuntu1~16.04.4) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 78b6f8b2ed219a71c67c16db887e4800
testgcc.c: In function ‘main’:
testgcc.c:4:12: warning: multi-character character constant [-Wmultichar]
char a = 'a';
^
testgcc.c:4:12: warning: overflow in implicit constant conversion
[-Woverflow]
testgcc.c:5:10: warning: embedded ‘\0’ in format [-Wformat-contains-nul]
printf("Size of char : %d\n",sizeof(a));
^
testgcc.c:5:10: warning: too many arguments for format [-Wformat-extra-args]
testgcc.c:6:39: warning: multi-character character constant [-Wmultichar]
printf("Size of char : %d\n",sizeof('a'));
^
testgcc.c:6:10: warning: embedded ‘\0’ in format [-Wformat-contains-nul]
printf("Size of char : %d\n",sizeof('a'));
^
testgcc.c:6:10: warning: too many arguments for format [-Wformat-extra-args]
testgcc.c:8:0: internal compiler error: character 0xa is not unibyte in
execution character set
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Is it appropriate for me to create a bug report on GCC's bugzillia?
--
Yubin
Re: [std-discussion] Is this union aliasing code well-defined?
+Cc gcc-list.
Does any gcc developer have any comments?
On Mon, Sep 25, 2017 at 01:41:55PM -0700, Myriachan wrote:
> This question that "supercat" posted on Stack Overflow ran into an
> interesting problem:
>
> https://stackoverflow.com/questions/46205744/is-this-use-of-unions-strictly-conforming/
>
> A copy of the code involved is as follows:
>
> struct s1 {unsigned short x;};
> struct s2 {unsigned short x;};
> union s1s2 { struct s1 v1; struct s2 v2; };
>
> static int read_s1x(struct s1 *p) { return p->x; }
> static void write_s2x(struct s2 *p, int v) { p->x=v;}
>
> int test(union s1s2 *p1, union s1s2 *p2, union s1s2 *p3)
> {
> if (read_s1x(&p1->v1))
> {
> unsigned short temp;
> temp = p3->v1.x;
> p3->v2.x = temp;
> write_s2x(&p2->v2,1234);
> temp = p3->v2.x;
> p3->v1.x = temp;
> }
> return read_s1x(&p1->v1);
> }
> int test2(int x)
> {
> union s1s2 q[2];
> q->v1.x = 4321;
> return test(q,q+x,q+x);
> }
> #include
> int main(void)
> {
> printf("%d\n",test2(0));
> }
>
>
> Both GCC and Clang in -fstrict-aliasing mode with optimizations are acting
> as if they ran into undefined behavior, and return 4321 instead of the
> expected 1234. This happens in both C and C++ mode. Intel C++ and Visual
> C++ return the expected 1234. All four compilers hardwire the result as a
> constant parameter to printf rather than call test2 or modify memory at
> runtime.
>
> From my reading of the C++ Standard, particularly [class.union]/5,
> assignment expressions through a union member access changes the active
> member of the union (if the union member has a trivial default constructor,
> which it does here, being C code). Taking the address of p2->v2 and p1->v1
> ought to be legal because those are the active members of the union at the
> time their pointers are taken.
>
> Is this a well-defined program, or is there subtle undefined behavior
> happening here?
>
> Melissa
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-discussion+unsubscr...@isocpp.org.
> To post to this group, send email to std-discuss...@isocpp.org.
> Visit this group at
> https://groups.google.com/a/isocpp.org/group/std-discussion/.
Re: confirm subscribe to gcc@gcc.gnu.org
On Sat, Oct 28, 2017, at 12:06 AM, gcc-h...@gcc.gnu.org wrote: > Hi! This is the ezmlm program. I'm managing the > gcc@gcc.gnu.org mailing list. > > To confirm that you would like > >yub...@fastmail.com > > added to the gcc mailing list, please send > an empty reply to this address: > >gcc-sc.1509174385.nmbemkeeojmnoanlagae-yubinr=fastmail@gcc.gnu.org > > Usually, this happens when you just hit the "reply" button. > If this does not work, simply copy the address and paste it into > the "To:" field of a new message. > > This confirmation serves two purposes. First, it verifies that I am able > to get mail through to you. Second, it protects you in case someone > forges a subscription request in your name. > > Some mail programs are broken and cannot handle long addresses. If you > cannot reply to this request, instead send a message to > and put the > entire address listed above into the "Subject:" line. > > > --- Administrative commands for the gcc list --- > > I can handle administrative requests automatically. Please > do not send them to the list address! Instead, send > your message to the correct command address: > > To subscribe to the list, send a message to: > > > To remove your address from the list, send a message to: > > > Send mail to the following for info and FAQ for this list: > > > > Similar addresses exist for the digest list: > > > > To get messages 123 through 145 (a maximum of 100 per request), mail: > > > To get an index with subject and author for messages 123-456 , mail: > > > They are always returned as sets of 100, max 2000 per request, > so you'll actually get 100-499. > > To receive all messages with the same subject as message 12345, > send an empty message to: > > > The messages do not really need to be empty, but I will ignore > their content. Only the ADDRESS you send to is important. > > You can start a subscription for an alternate address, > for example "john@host.domain", just add a hyphen and your > address (with '=' instead of '@') after the command word: > > > To stop subscription for this address, mail: > > > In both cases, I'll send a confirmation message to that address. When > you receive it, simply reply to it to complete your subscription. > > If despite following these instructions, you do not get the > desired results, please contact my owner at > gcc-ow...@gcc.gnu.org. Please be patient, my owner is a > lot slower than I am ;-) > > --- Enclosed is a copy of the request I received. > > Return-Path: > Received: (qmail 4414 invoked by uid 48); 28 Oct 2017 07:06:24 - > Message-ID: <20171028070624.4411.qm...@sourceware.org> > From: anonym...@sourceware.org > Date: Sat, 28 Oct 2017 07:06:24 + > To: gcc-subscribe-yubinr=fastmail@sourceware.org > User-Agent: Heirloom mailx 12.4 7/29/08 > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > >
Re: [std-discussion] Is this union aliasing code well-defined?
On 10/27/2017 04:54 PM, Richard Biener wrote:
> On Fri, Oct 27, 2017 at 3:00 PM, Yubin Ruan wrote:
>> +Cc gcc-list.
>>
>> Does any gcc developer have any comments?
>
> See PR82224. The code is valid.
>
>> On Mon, Sep 25, 2017 at 01:41:55PM -0700, Myriachan wrote:
>>> This question that "supercat" posted on Stack Overflow ran into an
>>> interesting problem:
>>>
>>> https://stackoverflow.com/questions/46205744/is-this-use-of-unions-strictly-conforming/
>>>
>>> A copy of the code involved is as follows:
>>>
>>> struct s1 {unsigned short x;};
>>> struct s2 {unsigned short x;};
>>> union s1s2 { struct s1 v1; struct s2 v2; };
>>>
>>> static int read_s1x(struct s1 *p) { return p->x; }
>>> static void write_s2x(struct s2 *p, int v) { p->x=v;}
>>>
>>> int test(union s1s2 *p1, union s1s2 *p2, union s1s2 *p3)
>>> {
>>> if (read_s1x(&p1->v1))
>>> {
>>> unsigned short temp;
>>> temp = p3->v1.x;
>>> p3->v2.x = temp;
>>> write_s2x(&p2->v2,1234);
>>> temp = p3->v2.x;
>>> p3->v1.x = temp;
>>> }
>>> return read_s1x(&p1->v1);
>>> }
>>> int test2(int x)
>>> {
>>> union s1s2 q[2];
>>> q->v1.x = 4321;
>>> return test(q,q+x,q+x);
>>> }
>>> #include
>>> int main(void)
>>> {
>>> printf("%d\n",test2(0));
>>> }
>>>
>>>
>>> Both GCC and Clang in -fstrict-aliasing mode with optimizations are acting
>>> as if they ran into undefined behavior, and return 4321 instead of the
>>> expected 1234. This happens in both C and C++ mode. Intel C++ and Visual
>>> C++ return the expected 1234. All four compilers hardwire the result as a
>>> constant parameter to printf rather than call test2 or modify memory at
>>> runtime.
>>>
>>> From my reading of the C++ Standard, particularly [class.union]/5,
>>> assignment expressions through a union member access changes the active
>>> member of the union (if the union member has a trivial default constructor,
>>> which it does here, being C code). Taking the address of p2->v2 and p1->v1
>>> ought to be legal because those are the active members of the union at the
>>> time their pointers are taken.
>>>
>>> Is this a well-defined program, or is there subtle undefined behavior
>>> happening here?
Thanks.
As put in my stackoverflow answer[1], I believe this behavior is specified in
the GCC-online-doc, in section `-fstrict-alisgin'[2]:
Pay special attention to code like this:
union a_union {
int i;
double d;
};
int f() {
union a_union t;
t.d = 3.0;
return t.i;
}
The practice of reading from a different union member than the one most
recently written to (called *type-punning*) is common. Even with
*-fstrict-aliasing*, type-punning is allowed, provided the memory is
accessed through the union type. So, the code above works as expected.
See Structures unions enumerations and bit-fields implementation.
However, this code might not:
int f() {
union a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}
Similarly, access by taking the address, casting the resulting pointer
and dereferencing the result has undefined behavior, even if the cast
uses a union type, e.g.:
int f() {
double d = 3.0;
return ((union a_union *) &d)->i;
}
The -fstrict-aliasing option is enabled at levels -O2, -O3, -Os.
I think the second example above is similar to the OP's question (although the
C standard might not say so... so from my perspective if the second example
above is true, the OP's code is invalid.
Do anyone have any comment?
Yubin
[1]:
https://stackoverflow.com/questions/46205744/is-this-use-of-unions-strictly-conforming/46968235?noredirect=1#comment80930683_46968235
[2]: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
