Index
> Main > Multiple section fragments |
| Author |
|
|
l_inc 21 Jun 2015, 22:55
alexfru
Quote: Can this be fixed in FASM? As long as the Smaller C compiler is fixed to not produce torn sections... Fasm is not supposed to collect equally named sections together: it would just be contradictory to its very name. "Flat" means in particular that whatever code or data you define it will have exactly the same layout in the binary as it has in the source code. Another option is to make Smaller C include some macros into the produced source. E.g. you can redefine the section directive with a macro that would collect whole sections into macro bodies. In either case you need to adjust the Smaller C compiler accordingly. _________________ Faith is a superposition of knowledge and fallacy |
|||
21 Jun 2015, 22:55 |
|
|
alexfru 22 Jun 2015, 01:52
l_inc wrote: alexfru Ain't gonna happen any time soon. You see, it's a single pass compiler with minimum buffering, which is what makes it very small and simple. And when things start overlapping, e.g. like here: Code: char* apc[] = { "abc", "rst", "xyz" }; there isn't much to be done other than emit them overlapping for the assembler to combine properly. The character data goes into .rodata and the pointers (apc[0], apc[1], apc[2]) go into .data. The assembler is usually capable of making several passes over the input in order to resolve forward references or use shortest branch instructions. I see FASM proudly reports 21 passes on one of my files. At first glance, it looks like it could do more passes to combine section fragments. l_inc wrote: Fasm is not supposed to collect equally named sections together: it would just be contradictory to its very name. Well, then probably Smaller C and FASM are both too primitive to work together. l_inc wrote: "Flat" means in particular that whatever code or data you define it will have exactly the same layout in the binary as it has in the source code. But we aren't talking about a flat binary. We're talking about an ELF intermediate object file, which FASM claims to be supporting and to a certain degree that's true. I'm not exactly sure if inconsistent section flags/attributes or multiple sections of the same name are allowed within the same ELF object file. l_inc wrote: Another option is to make Smaller C include some macros into the produced source. E.g. you can redefine the section directive with a macro that would collect whole sections into macro bodies. You mean like start with an empty macro and then change what is normally "section ".text" executable" into some kind of other macro that would append its argument (the rest of the code that's supposed to be in the .text section) to the first macro and then expand it at the end? And then there's "inline assembly" support of the form asm("text"), which outputs the text as-is and that text too could contain section directives... It gets complicated. l_inc wrote: In either case you need to adjust the Smaller C compiler accordingly. Yeah, that's what I'm playing with. I changed the syntax to suit FASM and then ran into this issue with sections. I might be able to make some adjustments in the linker to allow for the unconventional ELF files produced by FASM. E.g. I could just ignore alignment reported in ELF and just concatenate all the fragments. Most things will work as the CPU isn't very picky to alignment of data, but some, where the CPU is picky, won't. I think, it could be worked around / fixed if I can specify section alignment explicitly. E.g. when an aligned object starts, I emit a section with alignment of 4, but when I need to continue that section, I set its alignment to 1. But I can't see such an option (to set section alignment) in the documentation and by default all sections come out aligned to 4 bytes. Is there such an option? |
|||
|
22 Jun 2015, 01:52 |
|
|
l_inc 22 Jun 2015, 13:00
alexfru
Quote: At first glance, it looks like it could do more passes to combine section fragments. This task can be done in a single pass. Multiple passes a meant to resolve other things. Quote: But we aren't talking about a flat binary. It doesn't matter. The "flatness" property holds for all output formats and can only be visually overridden using the preprocessor capabilities. Quote: I'm not exactly sure if inconsistent section flags/attributes or multiple sections of the same name are allowed within the same ELF object file. Equally named sections are explicitly allowed: Executable and Linkable Format. Special Sections wrote: An object file may have more than one section with the same name. Quote: You mean like start with an empty macro and [...] and then expand it at the end? There are different ways to implement this. I'm gonna show you one. Put the following at the very beginning of your compiler output: Code: macro section args& { include 'macrosection.inc' mSection args } Put an invocation putsections at the very end of your compiler output (postpone is not able to handle this situation). And here is the content of the "macrosection.inc": Code: ; macrosection.inc: section fix } mSection realsection fix section putsections fix } mPutSections match, { local descriptors macro mSection args& \{ match name \rest, args + \\{ \\local sbody irpv d,descriptors \\\{ common match name sect \\\rest, d + \\\\{ define sect sbody rept 0 \\\\\{ \\\\} \\\} match, \\\{ \\\local wrap,sect,shead define sect shead define sect sbody define wrap sect define descriptors name wrap shead equ realsection args \\\} macro sbody \\\{ \\} \} macro mPutSections \{ irpv d,descriptors \\{ match name sect, d \\\{ irpv s,sect \\\\{ s \\\\} \\\} \\} \} } This creates a list of section descriptors. Each descriptor consists of a tuple: section name and a list of its corresponding section bodies. putsections at the end is supposed to finalize the last macroblock and to invoke a section instantiation macro. Section properties are not checked for consistency, but it's not much of a problem to add the checks either. Note that this way you are not allowed to explicitly define macroblocks inside sections, which is normally not a good style anyway. Quote: And then there's "inline assembly" support of the form asm("text"), which outputs the text as-is and that text too could contain section directives... This is processed by the Smaller C compiler anyway. So it doesn't matter what features you allow for your compiler as long as the intermediate output is acceptable for fasm. Quote: I think, it could be worked around / fixed if I can specify section alignment explicitly [...] But I can't see such an option (to set section alignment) in the documentation and by default all sections come out aligned to 4 bytes. You are thinking too complicated IMHO. But fasm surely does allow to specify section alignment: 2.4.4. Executable and Linkable Format wrote: optionally also align operator followed by the number specifying the alignment of section (it has to be the power of two), if no alignment is specified, the default value is used _________________ Faith is a superposition of knowledge and fallacy |
|||
|
22 Jun 2015, 13:00 |
|
|
revolution 22 Jun 2015, 15:18
alexfru : Perhaps I can point you towards an already existing topic concerning combining multiple parts of things into a single section (or sections) by building lists of each section and using postpone or manually placing the built sections in the order of your choosing.
|
|||
|
22 Jun 2015, 15:18 |
|
|
alexfru 02 Jul 2015, 05:33
OK, I did miss the section alignment option in the ELF format. However, if I use it to align a section to 1 byte, then I can't use an alignment directive to align to 4 bytes inside this section. I get an error about FASM's inability to provide/guarantee such internal alignment.
As for the macros, did I get it right that these are extremely expensive memory-wise? E.g. if I have an asm file of 50K lines, will it cause FASM's macros eat many megabytes of RAM? |
|||
|
02 Jul 2015, 05:33 |
|
|
l_inc 02 Jul 2015, 12:11
alexfru
Quote: However, if I use it to align a section to 1 byte, then I can't use an alignment directive to align to 4 bytes inside this section. That is correct. And letting the linker combine sections inside of a single object file is not a proper solution for your problem anyway. Quote: As for the macros, did I get it right that these are extremely expensive memory-wise? They obviously do consume memory, but not as much as you think. The consumption grows linearly with the number of lines, which is the same as if you don't use any macros at all. I must admit that in case you don't have to use the standard section declaration syntax, you'd probably better stick to the list building macros suggested by revolution: the proper solutions are at the end of the linked topic. In this case the grouping key for combining section bodies would be a name of a unique symbolic constant and the grouping would be implicitly resolved by fasm mechanisms. In the macros I provided the grouping is made explicitly with a match directive using actual section names as keys, which might involve a bit of additional overhead. _________________ Faith is a superposition of knowledge and fallacy |
|||
|
02 Jul 2015, 12:11 |
|
< Last Thread | Next Thread > |
Forum Rules:
|