Alan Cox wrote:
>
> > > This is not correct, Linus please don't apply.
> > I think it is, Jeff. Try this patch:
>
> Ok you are demonstrating a compiler feature we really don't need. You do need
> to make a new string. You also therefore need to fix every case we free a
> network device, remembering the names may pretty arbitarily be a constant.
>
> Is there a way to tell egcs to give unique strings for a given array.
Here's the story:
struct thing
{
char *s;
int i;
};
struct thing t1 = { "foo", 4 };
struct thing t2 = { "foo", 4 };
Compiled normally this will put a single instance of "foo" into the
read-only data section .rodata.
Compiled with '-fwritable-strings' the compiler will put _two_ copies of
"foo" into the writable data section .data.
However I'm not sure this is a good idea - it will prevent quite a bit
of (usually desirable) string sharing. One embedded systems the .data
section would have to be copied out to RAM at boot, so
-fwritable-strings will use more RAM.
Plus... Shouldn't the kernel be marking the .rodata pages as
read-only? We should really be faulting on a write to .rodata (and
.text!).
The code Tim has found won't work if, for example, the kernel is put in
ROM. I think strdup()ing it is the right thing to do.
> If not
> then we probably need to preprocess the file (Im not doing this by hand that
> is for sure) to generate lots of little 8 byte arrays and link each structure
> element to its own private array entry.
But they really should be moved out of .rodata if we're going to write
to them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:32 EST