pcc puts all const data in writable .data when using -fPIC

[Rich Felker]

There's been some interest in using pcc with musl libc on Linux (both
to compile the libc and for applications), which seems to be mostly or
fully working at this point; however, one major issue I just ran
across is that, when compiling position-independent code, all const
tables end up in .data rather than .text/.rodata. Naturally some such
tables belong in .data if they contain any non-null pointers, since
they'll be subject to relocations at load time by the dynamic linker.
However, for const data that does not contain pointers, having it in
.data is highly undesirable:

- It prevents the ability to detect bugs from applications attempting
to write to the data.

- It massively increases the commit charge needed.

In the case of musl libc.so, compiling with gcc gives only 1104 bytes
of .data, whereas compiling with pcc gives 180k of .data. The
difference is all constant tables: character properties, iconv mapping
tables, crypto constant tables, error strings, math coefficients,
state machines, etc.

Is there any easy way to fix this, or is it presently too difficult to
track whether the data object will contain relocations? A fix would be
much appreciated and would help make pcc a useful demo tool for us
(we're thinking of putting a jslinux image online with pcc and musl)
as well as a useful compiler for many of our users (who want something
BSD licensed that's not LLVM).

Rich

[Anders Magnusson]

Hi Rich,

Post by Rich Felker
There's been some interest in using pcc with musl libc on Linux (both
to compile the libc and for applications), which seems to be mostly or
fully working at this point; however, one major issue I just ran
across is that, when compiling position-independent code, all const
tables end up in .data rather than .text/.rodata. Naturally some such
tables belong in .data if they contain any non-null pointers, since
they'll be subject to relocations at load time by the dynamic linker.
However, for const data that does not contain pointers, having it in
- It prevents the ability to detect bugs from applications attempting
to write to the data.
- It massively increases the commit charge needed.
In the case of musl libc.so, compiling with gcc gives only 1104 bytes
of .data, whereas compiling with pcc gives 180k of .data. The
difference is all constant tables: character properties, iconv mapping
tables, crypto constant tables, error strings, math coefficients,
state machines, etc.
Is there any easy way to fix this, or is it presently too difficult to
track whether the data object will contain relocations? A fix would be
much appreciated and would help make pcc a useful demo tool for us
(we're thinking of putting a jslinux image online with pcc and musl)
as well as a useful compiler for many of our users (who want something
BSD licensed that's not LLVM).

Const data should be put in a readonly segment, otherwise it's a bug.

Can you:
1) tell which pcc version and architecture you are using
2) Give an example of what ends up in the wrong segment

so that I can look at it? It should be simple to fix.

-- Ragge

[Rich Felker]

Post by Anders Magnusson
Const data should be put in a readonly segment, otherwise it's a bug.
1) tell which pcc version and architecture you are using

pcc 1.1.0.DEVEL 20130227 for i686-pc-linux-gnulibc1

("gnulibc1" is what pcc's configure script wrongly identifies musl as)

Post by Anders Magnusson
2) Give an example of what ends up in the wrong segment

pccdata.c:
const int x[] = { 1, 2, 3 };

$ pcc -c pccdata.c
$ size pccdata.o
text data bss dec hex filename
12 0 0 12 c pccdata.o
$ pcc -c -fPIC pccdata.c
$ size pccdata.o
text data bss dec hex filename
0 12 0 12 c pccdata.o

Post by Anders Magnusson
so that I can look at it? It should be simple to fix.

Thanks!

Rich