From: Tim Abbott on 14 Jun 2010 18:10 On Mon, 14 Jun 2010, James Bottomley wrote: > On Mon, 2010-06-14 at 20:33 +0100, Matt Fleming wrote: > > On Mon, 14 Jun 2010 10:32:46 -0400 (EDT), Tim Abbott <tabbott(a)ksplice.com> wrote: > > > > > > I was planning to submit in the next couple weeks a change that adds > > > support for building the kernel with -ffunction-sections -fdata-sections, > > > which would have as a piece of it adding to TEXT_TEXT the following > > > expression: > > > > > > *(.text.[A-Za-z$_]*) /* handle -ffunction-sections */\ > > Just as a point of technical interest, that won't handle > -ffunction-sections. At least on parisc, we get a > section .text.<function name> for every function. This means that any > character legal in a function name can appear there, not just letters > and underscores (we get millicode ones with dollar signs as well for > instance). That's why *(.text.*) is safer Hi James, I believe that the pattern [A-Za-z$_] matches all valid characters to start a function name (in particular, it includes "$"). If I'm missing any valid characters for the start of a function name, please correct me. To give some background, the strategy here for -ffunction-sections support is to have the kernel's "magic" text sections all start with ".text.." while the sections generated by -ffunction-sections will start with ".text." followed by a character other than "." These sets are disjoint, and so if we have a complete set of valid next characters in the pattern ".text.[A-Za-z$_]*", it will be just as good as ".text.*" for matching the sections produced by -ffunction-sections. (As a sidenote, I would prefer .text.[^.], but I don't believe that is valid linker script syntax). While one could in principle try to handle things by not renaming the ..text.foo sections and instead just placing the linker script code for them all before a .text.* item in the linker script, that approach is really fragile. I think the "text..foo" approach is a good design and I am not aware of any problems with it. Some more detailed explanation is available here: <http://lkml.org/lkml/2010/2/19/365> > > > which should match the .text.foo sections generated by -ffunction-sections > > > but not the kernel's special sections which now all have names of the form > > > .text..foo. > > They do? I don't find any symbols like that on parisc. > > Historically, the way we've differentiated is that kernel special > symbols tend to have the text designator *after* the name, whereas the > linker puts it before ... of course that has issues for functions > called things like text or init ... but we try not to do that ... It looks like the patches for the .text.foo rename haven't been sent yet, my mistake. I've primarily been tracking the much larger .data.foo -> ..data..foo transition. I expect a patch series to rename the remaining sections and add -ffunction-sections support will be sent by either Denys Vlasenko or myself in the next few weeks. While the kernel does use section names like ".init.text", there were before quite recently a very large number of kernel special sections with names like ".data.page_aligned" which would conflict with: static int page_aligned; when compiling with -fdata-sections. In fact, we initially sent patches that changed these all to e.g. ".page_aligned.data". But we discovered that it is problem when writing assembly files, since if you write: ..section ".page_aligned.data" it doesn't work -- you need to specify the load flags like so: ..section ".page_aligned.data", "aw" while if you write e.g. ..section ".data..page_aligned" the assembler will automatically set the right load flags for read/write data. Since this is a subtle issue and I'd be surprised if there weren't a lot of people who work on assembly code in the kernel who don't know about this subtle issue, the ".page_aligned.data" naming scheme is destined to result in some frustrating bugs. So we settled on the more bug-proof ".data..page_aligned" naming scheme for adding -fdata-sections support. It would probably be a good cleanup to go through and rename e.g. ..init.text to .text..init so that we're consistent everywhere, but I'd like to get -ffunction-sections working before starting that project myself. -Tim Abbott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tim Abbott on 14 Jun 2010 18:30 On Mon, 14 Jun 2010, Matt Fleming wrote: > Do these special kernel sections include things like the parisc > .text.do_softirq, .text.sys_exit, etc? James raised a good objection to > the parisc patch of this series. I'm guessing most people saw it already > but I'll paste it here for reference, > > This would destroy all of the named parisc text ordering we do above the > removed line because now you'd have swept up all the function sections > before we get to them, won't it? > > The ordering is an execution speed up on 32 bit systems because our > relative jump is so short. > > Will you changes handle this OK? I think I addressed this in my reply to James just now, but to be super clear, this -ffunction-sections plan involves renaming .text.do_softirq to ..text..do_softirq (etc.) first. -Tim Abbott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 14 Jun 2010 19:10 On Mon, 2010-06-14 at 18:02 -0400, Tim Abbott wrote: > On Mon, 14 Jun 2010, James Bottomley wrote: > > > On Mon, 2010-06-14 at 20:33 +0100, Matt Fleming wrote: > > > On Mon, 14 Jun 2010 10:32:46 -0400 (EDT), Tim Abbott <tabbott(a)ksplice.com> wrote: > > > > > > > > I was planning to submit in the next couple weeks a change that adds > > > > support for building the kernel with -ffunction-sections -fdata-sections, > > > > which would have as a piece of it adding to TEXT_TEXT the following > > > > expression: > > > > > > > > *(.text.[A-Za-z$_]*) /* handle -ffunction-sections */\ > > > > Just as a point of technical interest, that won't handle > > -ffunction-sections. At least on parisc, we get a > > section .text.<function name> for every function. This means that any > > character legal in a function name can appear there, not just letters > > and underscores (we get millicode ones with dollar signs as well for > > instance). That's why *(.text.*) is safer > > Hi James, > > I believe that the pattern [A-Za-z$_] matches all valid characters to > start a function name (in particular, it includes "$"). If I'm missing > any valid characters for the start of a function name, please correct me. Well, our linker seems to generate annoying symbols with carets in them ... > To give some background, the strategy here for -ffunction-sections support > is to have the kernel's "magic" text sections all start with > > ".text.." > > while the sections generated by -ffunction-sections will start with > > ".text." followed by a character other than "." > > These sets are disjoint, and so if we have a complete set of valid next > characters in the pattern ".text.[A-Za-z$_]*", it will be just as good as > ".text.*" for matching the sections produced by -ffunction-sections. (As > a sidenote, I would prefer .text.[^.], but I don't believe that is valid > linker script syntax). > > While one could in principle try to handle things by not renaming the > .text.foo sections and instead just placing the linker script code for > them all before a .text.* item in the linker script, that approach is > really fragile. I think the "text..foo" approach is a good design and I > am not aware of any problems with it. OK, but how about some actual explanation? You've just characterised the current -ffunction-sections scheme that parisc has used for decades as "fragile" > Some more detailed explanation is available here: > <http://lkml.org/lkml/2010/2/19/365> That's still a bit short on explanations. But if I infer from the rest, someone, somewhere broke the convention that all our special linux sections be called .XX.data and .XX.text to distinguish them from the .text.FF and .data.YY the compiler will generate with the relevant sectional directives? because it's been working OK for us for a while. To fix the breakage, the proposal now is to name all linux special sections as .text..XX and .data..XX? I can see that's more standard looking that XX.text and XX.data, but not necessarily that it's better. This then introduces a problem of matching because .text.X and .text..X are hard to distinguish using the linker matching scripts. So even if I buy the rename of the linux symbols, what about using a linker defined symbol that's illegal as a function as the initial separator instead of .? So hyphen looks the obvious one ... you can have all the linux special sections being .text- and .data- then we can easily distinguish. James > > > > which should match the .text.foo sections generated by -ffunction-sections > > > > but not the kernel's special sections which now all have names of the form > > > > .text..foo. > > > > They do? I don't find any symbols like that on parisc. > > > > Historically, the way we've differentiated is that kernel special > > symbols tend to have the text designator *after* the name, whereas the > > linker puts it before ... of course that has issues for functions > > called things like text or init ... but we try not to do that ... > > It looks like the patches for the .text.foo rename haven't been sent yet, > my mistake. I've primarily been tracking the much larger .data.foo -> > .data..foo transition. I expect a patch series to rename the remaining > sections and add -ffunction-sections support will be sent by either Denys > Vlasenko or myself in the next few weeks. > > While the kernel does use section names like ".init.text", there were > before quite recently a very large number of kernel special sections with > names like ".data.page_aligned" which would conflict with: > > static int page_aligned; > > when compiling with -fdata-sections. > > In fact, we initially sent patches that changed these all to e.g. > ".page_aligned.data". But we discovered that it is problem when writing > assembly files, since if you write: > > .section ".page_aligned.data" > > it doesn't work -- you need to specify the load flags like so: > > .section ".page_aligned.data", "aw" > > while if you write e.g. > > .section ".data..page_aligned" > > the assembler will automatically set the right load flags for read/write > data. > > Since this is a subtle issue and I'd be surprised if there weren't a lot > of people who work on assembly code in the kernel who don't know about > this subtle issue, the ".page_aligned.data" naming scheme is destined to > result in some frustrating bugs. So we settled on the more bug-proof > ".data..page_aligned" naming scheme for adding -fdata-sections support. > > It would probably be a good cleanup to go through and rename e.g. > .init.text to .text..init so that we're consistent everywhere, but I'd > like to get -ffunction-sections working before starting that project > myself. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: James Bottomley on 14 Jun 2010 19:20 On Mon, 2010-06-14 at 18:21 -0400, Tim Abbott wrote: > On Mon, 14 Jun 2010, Matt Fleming wrote: > > > Do these special kernel sections include things like the parisc > > .text.do_softirq, .text.sys_exit, etc? James raised a good objection to > > the parisc patch of this series. I'm guessing most people saw it already > > but I'll paste it here for reference, > > > > This would destroy all of the named parisc text ordering we do above the > > removed line because now you'd have swept up all the function sections > > before we get to them, won't it? > > > > The ordering is an execution speed up on 32 bit systems because our > > relative jump is so short. > > > > Will you changes handle this OK? > > I think I addressed this in my reply to James just now, but to be super > clear, this -ffunction-sections plan involves renaming .text.do_softirq to > .text..do_softirq (etc.) first. OK, so that doesn't make a lot of sense to me; I suspect because you don't understand what parisc is doing. These aren't names of linux special sections ... they're names of function sections. For efficiency, we take specific hot functions and place them together in the linker script so the jumps between them are small enough to be coded as relative on the 32 bit architecture. It's really just a more efficient way of laying out the binary. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tim Abbott on 14 Jun 2010 22:50 On Mon, 14 Jun 2010, James Bottomley wrote: > > I believe that the pattern [A-Za-z$_] matches all valid characters to > > start a function name (in particular, it includes "$"). If I'm missing > > any valid characters for the start of a function name, please correct me. > > Well, our linker seems to generate annoying symbols with carets in > them ... The question here is: is there C code that when compiled with -ffunction-sections will generate an ELF section with a name that starts with ".text.^"? For that to happen, you would need a function whose name started with "^", which isn't valid C. The relevant namespace here is the names for ELF sections generated by -ffunction-sections. These are in turn computed by the compiler from function names -- there's no potential conflict created by linker-generated symbols whose names start with a caret. Similarly, for -fdata-sections, we only care about the names of C data objects, which also can't start with a caret. > > While one could in principle try to handle things by not renaming the > > .text.foo sections and instead just placing the linker script code for > > them all before a .text.* item in the linker script, that approach is > > really fragile. I think the "text..foo" approach is a good design and I > > am not aware of any problems with it. > > OK, but how about some actual explanation? You've just characterised > the current -ffunction-sections scheme that parisc has used for decades > as "fragile" The current parisc situation is fine. What I was trying to draw a contrast with is supporting -fdata-sections by adding ".data.*" to DATA_DATA, and then trying to make sure that all the architecture linker scripts handle all the kernel's special data sections with names like ".data.foo" before the place where DATA_DATA appears in their linker scripts. Most of the architecture linker scripts mention more than a half dozen special kernel sections with names of the form ".data.foo", often in fairly random orders, and so it would be really fragile to add the constraint that these sections need to all appear above DATA_DATA. Adding ".data.[A-Za-z$_]" to DATA_DATA doesn't have this problem. If we similarly added ".text.[A-Za-z$_]" to TEXT_TEXT, we'd presumably move the 4 named .text.foo sections before TEXT_TEXT; I don't think any other architectures would require any work. > > Some more detailed explanation is available here: > > <http://lkml.org/lkml/2010/2/19/365> > > That's still a bit short on explanations. > > But if I infer from the rest, someone, somewhere broke the convention > that all our special linux sections be called .XX.data and .XX.text to > distinguish them from the .text.FF and .data.YY the compiler will > generate with the relevant sectional directives? because it's been > working OK for us for a while. I don't know the full history here. But prior to the ".data.foo" -> ".data..foo" patches that were merged recently, there were a bunch of cross-architecture sections with these sorts of names, e.g.: ..data.page_aligned ..data.nosave ..data.read_mostly ..data.cacheline_aligned ..data.lock_aligned ..data.percpu* ..data.init_task etc. There were also a bunch of ".text.foo" sections on individual architectures, many of which currently don't support -ffunction-sections (sh, ia64, x86, mips, etc.). However, there weren't any .text.foo sections that are cross-architecture. Since parisc only uses -ffunction-sections, and not -fdata-sections, the popular .data.foo naming scheme doesn't cause any breakage on parisc. The only architecture that does use -fdata-sections is frv, and there could theoretically have been breakage there, but in practice it's likely nobody has written kernel code that would actually conflict, e.g. "static int percpu = 3;", yet. > To fix the breakage, the proposal now is to name all linux special > sections as .text..XX and .data..XX? I can see that's more standard > looking that XX.text and XX.data, but not necessarily that it's better. Yes, that's the proposal. > This then introduces a problem of matching because .text.X and .text..X > are hard to distinguish using the linker matching scripts. Right. I believe that this is totally solvable with a simple linker script pattern, since the space of valid names for functions and data objects in C code is quite restricted (and that the implementation of using e.g. ".data.[A-Za-z$_]*" solves this problem). > So even if I buy the rename of the linux symbols, what about using a > linker defined symbol that's illegal as a function as the initial > separator instead of .? So hyphen looks the obvious one ... you can > have all the linux special sections being .text- and .data- then we can > easily distinguish. Is "." a valid first character for a function name? I don't see the problem with using "." here. Both .page_aligned.data and .data-page_aligned are valid choices (and in fact, the first patch series I sent on this topic about 18 months ago did ..page_aligned.data, I think). The main technical difference between ".data..page_aligned" and ".page_aligned.data" in my view is that you need to be more careful when writing assembly files with ".page_aligned.data". To give an example, if I run the following: $ cat > foo.s ..section .data-page-aligned .long 0 ..section .data.page_aligned .long 1 $ gcc -c foo.s -o foo.o $ objdump -h foo.o foo.o: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000000 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 00000034 2**2 ALLOC 3 .data-page-aligned 00000004 00000000 00000000 00000034 2**0 CONTENTS, READONLY 4 .data.page_aligned 00000004 00000000 00000000 00000038 2**0 CONTENTS, ALLOC, LOAD, DATA one can see that the .data-page-aligned section doesn't have the right section flags. So I'm pretty sure the relevant assembler heuristic is looking for things starting with ".data.", not just ".data". The kernel has a lot of code in assembly files that just does: ..section ".data" and so there's a very real risk that folks who are doing pattern-matching development on assembly files will end up creating non-allocated sections by accident (I've certainly made this mistake myself, and there's a bug of this form in arch/x86/lib/thunk.S until commit c6c2d7a084d14a8a701be84872aa1b77d2945f46, so I don't think I'm alone) I also think that ".data..page_aligned" is more readable as a new name for the former ".data.page_aligned" than ".page_aligned.data" is, but I think that's a secondary consideration. ".data.-page_aligned" would be technically equivalent to ".data..page_aligned", but I think it is uglier. -Tim Abbott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: Uprobes Implementation Next: Treat as urgent and important. |