removal of "static foo = 0" from drivers/ide (test11)
Quoted 6 lines
What information is lost? Unless you're working on a really strange machine which does not zero bss, the following means the same from the codes point of view:
static int foo = 0;
static int foo;
I think the argument is that "static int foo;" implies you don't actually care how "foo" is initialized, but adding the "= 0" is revealing that the code actually relies on the default value. The code is obviously equivalent. It is a readability issue, not an issue of what the code does.
I would contend that it is a compiler bug in gcc if it treats the two statements differently, since they are trivially equivalent. I guess that it has been decided that linux kernel coding style dictates no zero initializers, so that's that. Personally, I prefer symmetry: if I have a list of static variables initialized to various things, I don't have to use a different form for ones that are zero initialized.
Did the savings really work out to be measured in kb's of space? I would have expected compression to eliminate most of the savings.
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · David Hinds
I would contend that it is a compiler bug in gcc if it treats the two statements differently, since they are trivially equivalent. I guess that it has been decided that linux kernel coding style dictates no zero initializers, so that's that. Personally, I prefer symmetry: if I have a list of static variables initialized to various things, I don't have to use a different form for ones that are zero initialized.
I would contend that you are wrong -- it is not a compiler bug.
First, they are not trivially equivalent. In fact, they are not equivalent at all. Any good C book should tell you that one places data in "data segment" and another in "bss segment" (with a footnote explaining historical meaning of "block started by symbol")
Second, If compiler did the ".data -> .bss" move on the fly then it would violate the principle of least surprize. For example a programmer could expect the variable to be in .data for binary patching the object (this reason is not applicable to the Linux kernel because section information is lost when converting vmlinux to raw binary and then onto bzImage).
Quoted 4 lines
Did the savings really work out to be measured in kb's of space? I would have expected compression to eliminate most of the savings.
if one doesn't count compression then -- hundreds of Kbs (K=1024 and b = byte, not bit!). Even Mbs if you count multiple architectures.
Use Keith Owens' famous perl script to do the counting.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
[Tigran Aivazian]
Quoted 4 lines
First, they are not trivially equivalent. In fact, they are not equivalent at all. Any good C book should tell you that one places data in "data segment" and another in "bss segment" (with a footnote explaining historical meaning of "block started by symbol")
Do you have an ISO C standard to refer to? I don't, but my guess is that the standard does not even *mention* discreet data sections. It *does* say that globals and statics are implicitly initialized to 0 -- the rest is a mere implementation issue.
So yes, the two statements *are* trivially equivalent, unless I'm wrong and the standard *does* talk about data sections.
Quoted 2 lines
For example a programmer could expect the variable to be in .data for binary patching the object
Binary patching? If you are binary patching something you need to get the exact location, one way or another. Whatever tool you use to extract the location of a symbol in an object file, that same tool should tell you which section it is in. If the tool only looks in '.data', it is flawed.
[David Hinds]
Quoted 2 lines
Quoted 2 lines
Did the savings really work out to be measured in kb's of space? I would have expected compression to eliminate most of the savings.
Some boot targets are not compressed. And the variables are scattered through the .data section rather than all in one place, so the 0s may not compress as well as you'd think.
Anyway, by some estimates 'vmlinux' has gone down by several kilobytes due to these patches. Obviously the exact savings depend on .config .
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Peter Samuelson
Binary patching? If you are binary patching something you need to get the exact location, one way or another. Whatever tool you use to extract the location of a symbol in an object file, that same tool should tell you which section it is in. If the tool only looks in '.data', it is flawed.
The whole point of bss is that it does not have any space allocated in the object on disk. bss is just a section entry saying "this size, at this location", the area is allocated and zeroed at load time. Binary patches against bss on disk cannot work, there is nothing to patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
[Keith Owens]
Quoted 2 lines
Binary patches against bss on disk cannot work, there is nothing to patch.
OK, me dumkopf.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · Peter Samuelson
[Tigran Aivazian]
Quoted 4 lines
First, they are not trivially equivalent. In fact, they are not equivalent at all. Any good C book should tell you that one places data in "data segment" and another in "bss segment" (with a footnote explaining historical meaning of "block started by symbol")
Quoted 7 lines
Do you have an ISO C standard to refer to? I don't, but my guess is that the standard does not even *mention* discreet data sections. It *does* say that globals and statics are implicitly initialized to 0 -- the rest is a mere implementation issue.
So yes, the two statements *are* trivially equivalent, unless I'm wrong and the standard *does* talk about data sections.
no, I was not talking about ISO C standards but about the normal expected C environment under any UNIX. I guess, we just mean different things by "trivially equivalent" since neither of us said anything about what that actually meant. What I meant by that was "not only imply the same logic for the program but correspond to the same physical locations (if any) on the resulting object file". In this sense, obviously, they are not "trivially equivalent" since in one case there is no physical location at all -- that is the whole point of having bss at all.
Quoted 9 lines
Quoted 3 lines
For example a programmer could expect the variable to be in .data for binary patching the object
Binary patching? If you are binary patching something you need to get the exact location, one way or another. Whatever tool you use to extract the location of a symbol in an object file, that same tool should tell you which section it is in. If the tool only looks in '.data', it is flawed.
Keith already pointed out why you are wrong there.
Quoted 11 lines
[David Hinds]
Quoted 2 lines
Quoted 2 lines
Did the savings really work out to be measured in kb's of space? I would have expected compression to eliminate most of the savings.
Some boot targets are not compressed. And the variables are scattered through the .data section rather than all in one place, so the 0s may not compress as well as you'd think.
Anyway, by some estimates 'vmlinux' has gone down by several kilobytes due to these patches. Obviously the exact savings depend on .config .
"several" kilobytes? _My_ patches alone (accepted by Linus ages ago) reduced it by >280K.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
[Tigran Aivazian <[email protected]>]
Quoted 6 lines
no, I was not talking about ISO C standards but about the normal expected C environment under any UNIX. I guess, we just mean different things by "trivially equivalent" since neither of us said anything about what that actually meant. What I meant by that was "not only imply the same logic for the program but correspond to the same physical locations (if any) on the resulting object file".
OK, so we do mean two different things. As far as standard C is concerned, the location of your global variables is none of your business, as long as they can be addressed with a pointer of the appropriate type. By the time you get to caring about what section something goes in, you're way beyond standard C, and you need to start looking at the gcc __attribute__(("section")) extension, and possibly an ld link script.
So I guess to me "trivially equivalent" meant that a standards- conforming C program would never notice the difference. As such, I think -fassume-bss-zero would be an entirely reasonable default for a C compiler, just as reasonable as reordering globals within a section (and nobody seems to be questioning gcc's right to do *that*).
It would probably also be reasonable to document it and provide an option to switch it off.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · Peter Samuelson
It would probably also be reasonable to document it and provide an option to switch it off.
yes, that is perfectly fine by me. Now, who is going to do the _work_? :)
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/