* arm-none-eabi-as: what decides .text section alignment/padding? @ 2023-06-19 7:14 Alexandru Onea 2023-06-19 13:31 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 5+ messages in thread From: Alexandru Onea @ 2023-06-19 7:14 UTC (permalink / raw) To: binutils [-- Attachment #1: Type: text/plain, Size: 2898 bytes --] Hello, community! I am playing with arm-none-eabi-as trying to understand how it aligns sections. I have the following source: ; source.s .text .byte 0xff .byte 0xff .byte 0xff I am inspecting the resulting object file: $ arm-none-eabi-as -mthumb -o source.o source.s $ arm-none-eabi-readelf -S source.o There are 8 section headers, starting at offset 0xec: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0* [ 1] .text PROGBITS 00000000 000034 000003 00 AX 0 0 1 * [ 2] .data PROGBITS 00000000 000037 000000 00 WA 0 0 1 [ 3] .bss NOBITS 00000000 000037 000000 00 WA 0 0 1 [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 000037 000014 00 0 0 1 [ 5] .symtab SYMTAB 00000000 00004c 000060 10 6 6 4 [ 6] .strtab STRTAB 00000000 0000ac 000004 00 0 0 1 [ 7] .shstrtab STRTAB 00000000 0000b0 00003c 00 0 0 1 The .text section is byte-aligned and contains the 3 bytes. Now, I add an instruction to source.s: ; source.s .text .byte 0xff nop .byte 0xff .byte 0xff Looking into the object file, now all of a sudden the .text section is halfword-aligned: There are 8 section headers, starting at offset 0x114: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0* [ 1] .text PROGBITS 00000000 000034 000006 00 AX 0 0 2 * [ 2] .data PROGBITS 00000000 00003a 000000 00 WA 0 0 1 [ 3] .bss NOBITS 00000000 00003a 000000 00 WA 0 0 1 [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 00003a 000014 00 0 0 1 [ 5] .symtab SYMTAB 00000000 000050 000080 10 6 8 4 [ 6] .strtab STRTAB 00000000 0000d0 000007 00 0 0 1 [ 7] .shstrtab STRTAB 00000000 0000d7 00003c 00 0 0 1 What is causing the assembler to decide to pad the section in the second case? I am confused because: 1. if the section is .data then the assembler will not pad it anyway, which makes sense, but 2. even if the section is .text, the assembler won't pad it unless it sees an instruction (I can have as many data directives, the section won't be padded without having also an instruction), and finally 3. the nop instruction is definitely not aligned and the assembler has no problem with it, but it still decides to care about section alignment. How is the assembler deciding here to align and pad the section? Can I force the assembler to not pad the .text section even if I have an instruction? Regards, Alexandru N. Onea ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: arm-none-eabi-as: what decides .text section alignment/padding? 2023-06-19 7:14 arm-none-eabi-as: what decides .text section alignment/padding? Alexandru Onea @ 2023-06-19 13:31 ` Richard Earnshaw (lists) 2023-06-19 16:01 ` Alexandru Onea 0 siblings, 1 reply; 5+ messages in thread From: Richard Earnshaw (lists) @ 2023-06-19 13:31 UTC (permalink / raw) To: Alexandru Onea, binutils On 19/06/2023 08:14, Alexandru Onea via Binutils wrote: > Hello, community! > > I am playing with arm-none-eabi-as trying to understand how it aligns > sections. I have the following source: > > ; source.s > .text > .byte 0xff > .byte 0xff > .byte 0xff > > I am inspecting the resulting object file: > > $ arm-none-eabi-as -mthumb -o source.o source.s > $ arm-none-eabi-readelf -S source.o > There are 8 section headers, starting at offset 0xec: > > Section Headers: > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al > [ 0] NULL 00000000 000000 000000 00 > 0 0 0* [ 1] .text PROGBITS 00000000 000034 > 000003 00 AX 0 0 1 > * [ 2] .data PROGBITS 00000000 000037 000000 00 > WA 0 0 1 > [ 3] .bss NOBITS 00000000 000037 000000 00 WA 0 0 1 > [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 000037 000014 00 0 0 1 > [ 5] .symtab SYMTAB 00000000 00004c 000060 10 6 6 4 > [ 6] .strtab STRTAB 00000000 0000ac 000004 00 0 0 1 > [ 7] .shstrtab STRTAB 00000000 0000b0 00003c 00 0 0 1 > > The .text section is byte-aligned and contains the 3 bytes. > > Now, I add an instruction to source.s: > > ; source.s > .text > .byte 0xff > nop > .byte 0xff > .byte 0xff > > Looking into the object file, now all of a sudden the .text section is > halfword-aligned: > > There are 8 section headers, starting at offset 0x114: > > Section Headers: > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al > [ 0] NULL 00000000 000000 000000 00 > 0 0 0* [ 1] .text PROGBITS 00000000 000034 > 000006 00 AX 0 0 2 > * [ 2] .data PROGBITS 00000000 00003a 000000 00 > WA 0 0 1 > [ 3] .bss NOBITS 00000000 00003a 000000 00 WA 0 0 1 > [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 00003a 000014 00 0 0 1 > [ 5] .symtab SYMTAB 00000000 000050 000080 10 6 8 4 > [ 6] .strtab STRTAB 00000000 0000d0 000007 00 0 0 1 > [ 7] .shstrtab STRTAB 00000000 0000d7 00003c 00 0 0 1 > > What is causing the assembler to decide to pad the section in the second > case? I am confused because: > > 1. if the section is .data then the assembler will not pad it anyway, > which makes sense, but > 2. even if the section is .text, the assembler won't pad it unless it > sees an instruction (I can have as many data directives, the section won't > be padded without having also an instruction), and finally > 3. the nop instruction is definitely not aligned and the assembler has > no problem with it, but it still decides to care about section alignment. > > How is the assembler deciding here to align and pad the section? Can I > force the assembler to not pad the .text section even if I have an > instruction? You've told the assembler to interpret the contents of the source file as containing thumb instructions. Thumb instructions must be (at least) two byte aligned (the fact that your source file deliberately misaligns the instruction is a bug in your code). If the section were not aligned then the linker would not be able to correctly merge consecutive sections if you had a mix of data-only text sections (like your first example) and sections containing code. Note that if you had used -marm instead of -mthumb the alignment would be set to 4 as all 'arm' instructions must be 4-byte aligned. R. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: arm-none-eabi-as: what decides .text section alignment/padding? 2023-06-19 13:31 ` Richard Earnshaw (lists) @ 2023-06-19 16:01 ` Alexandru Onea 2023-06-19 16:22 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 5+ messages in thread From: Alexandru Onea @ 2023-06-19 16:01 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: binutils [-- Attachment #1: Type: text/plain, Size: 4700 bytes --] Therefore, is it that the only difference between the two cases shown in my example boils down to whether the assembler sees an instruction or not? I understand it as follows: Case A: .text section with no instruction within, the assembler says "this monkey asks me to put data in a .text section, whatever, maybe where he comes from .text means something else" Case B: .text section with data and at least one instruction, the assembler says "this monkey now crosses the line, if he wants instructions, I must make sure that at least other .text sections can be merged into it" So does the assembler assume that if there are no instructions in a .text section, maybe it is not actually a .text section in the classical sense? Best regards, Alexandru N. Onea On Mon, 19 Jun 2023 at 16:31, Richard Earnshaw (lists) < Richard.Earnshaw@arm.com> wrote: > On 19/06/2023 08:14, Alexandru Onea via Binutils wrote: > > Hello, community! > > > > I am playing with arm-none-eabi-as trying to understand how it aligns > > sections. I have the following source: > > > > ; source.s > > .text > > .byte 0xff > > .byte 0xff > > .byte 0xff > > > > I am inspecting the resulting object file: > > > > $ arm-none-eabi-as -mthumb -o source.o source.s > > $ arm-none-eabi-readelf -S source.o > > There are 8 section headers, starting at offset 0xec: > > > > Section Headers: > > [Nr] Name Type Addr Off Size ES Flg > Lk Inf Al > > [ 0] NULL 00000000 000000 000000 00 > > 0 0 0* [ 1] .text PROGBITS 00000000 000034 > > 000003 00 AX 0 0 1 > > * [ 2] .data PROGBITS 00000000 000037 000000 00 > > WA 0 0 1 > > [ 3] .bss NOBITS 00000000 000037 000000 00 WA > 0 0 1 > > [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 000037 000014 00 > 0 0 1 > > [ 5] .symtab SYMTAB 00000000 00004c 000060 10 > 6 6 4 > > [ 6] .strtab STRTAB 00000000 0000ac 000004 00 > 0 0 1 > > [ 7] .shstrtab STRTAB 00000000 0000b0 00003c 00 > 0 0 1 > > > > The .text section is byte-aligned and contains the 3 bytes. > > > > Now, I add an instruction to source.s: > > > > ; source.s > > .text > > .byte 0xff > > nop > > .byte 0xff > > .byte 0xff > > > > Looking into the object file, now all of a sudden the .text section is > > halfword-aligned: > > > > There are 8 section headers, starting at offset 0x114: > > > > Section Headers: > > [Nr] Name Type Addr Off Size ES Flg > Lk Inf Al > > [ 0] NULL 00000000 000000 000000 00 > > 0 0 0* [ 1] .text PROGBITS 00000000 000034 > > 000006 00 AX 0 0 2 > > * [ 2] .data PROGBITS 00000000 00003a 000000 00 > > WA 0 0 1 > > [ 3] .bss NOBITS 00000000 00003a 000000 00 WA > 0 0 1 > > [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 00003a 000014 00 > 0 0 1 > > [ 5] .symtab SYMTAB 00000000 000050 000080 10 > 6 8 4 > > [ 6] .strtab STRTAB 00000000 0000d0 000007 00 > 0 0 1 > > [ 7] .shstrtab STRTAB 00000000 0000d7 00003c 00 > 0 0 1 > > > > What is causing the assembler to decide to pad the section in the second > > case? I am confused because: > > > > 1. if the section is .data then the assembler will not pad it anyway, > > which makes sense, but > > 2. even if the section is .text, the assembler won't pad it unless it > > sees an instruction (I can have as many data directives, the section > won't > > be padded without having also an instruction), and finally > > 3. the nop instruction is definitely not aligned and the assembler > has > > no problem with it, but it still decides to care about section > alignment. > > > > How is the assembler deciding here to align and pad the section? Can I > > force the assembler to not pad the .text section even if I have an > > instruction? > > You've told the assembler to interpret the contents of the source file > as containing thumb instructions. Thumb instructions must be (at least) > two byte aligned (the fact that your source file deliberately misaligns > the instruction is a bug in your code). If the section were not aligned > then the linker would not be able to correctly merge consecutive > sections if you had a mix of data-only text sections (like your first > example) and sections containing code. > > Note that if you had used -marm instead of -mthumb the alignment would > be set to 4 as all 'arm' instructions must be 4-byte aligned. > > R. > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: arm-none-eabi-as: what decides .text section alignment/padding? 2023-06-19 16:01 ` Alexandru Onea @ 2023-06-19 16:22 ` Richard Earnshaw (lists) 2023-06-19 16:39 ` Alexandru Onea 0 siblings, 1 reply; 5+ messages in thread From: Richard Earnshaw (lists) @ 2023-06-19 16:22 UTC (permalink / raw) To: Alexandru Onea; +Cc: binutils On 19/06/2023 17:01, Alexandru Onea via Binutils wrote: > Therefore, is it that the only difference between the two cases shown in my > example boils down to whether the assembler sees an instruction or not? > I understand it as follows: > > Case A: .text section with no instruction within, the assembler says "this > monkey asks me to put data in a .text section, whatever, maybe where he > comes from .text means something else" > Case B: .text section with data and at least one instruction, the assembler > says "this monkey now crosses the line, if he wants instructions, I must > make sure that at least other .text sections can be merged into it" > > So does the assembler assume that if there are no instructions in a .text > section, maybe it is not actually a .text section in the classical sense? Alignment is taken from the most aligned element in the section. It starts off at byte alignment and if you add an instruction with half-word alignment (thumb) it gets raised to that. If you add an instruction with word alignment (arm) it gets raised again. If you add an alignment directive with even higher alignment then that will dominate the overall alignment of the section. The only difference between this and, say, the .data section is that the alignment is implied by the instruction rather than explicitly requiring an alignment directive. A final note on this is that a .text section may contain both code and data. But the two are not the same and the assembler needs to keep track of them (especially on big-endian systems) so that byte swapping of instructions can be done correctly at link time. So don't try to fake up instructions by emitting .byte or similar directives, it will just lead to silent problems later on - use the .inst directive if you need to emit an opcode as binary. R. > > Best regards, > Alexandru N. Onea > > > On Mon, 19 Jun 2023 at 16:31, Richard Earnshaw (lists) < > Richard.Earnshaw@arm.com> wrote: > >> On 19/06/2023 08:14, Alexandru Onea via Binutils wrote: >>> Hello, community! >>> >>> I am playing with arm-none-eabi-as trying to understand how it aligns >>> sections. I have the following source: >>> >>> ; source.s >>> .text >>> .byte 0xff >>> .byte 0xff >>> .byte 0xff >>> >>> I am inspecting the resulting object file: >>> >>> $ arm-none-eabi-as -mthumb -o source.o source.s >>> $ arm-none-eabi-readelf -S source.o >>> There are 8 section headers, starting at offset 0xec: >>> >>> Section Headers: >>> [Nr] Name Type Addr Off Size ES Flg >> Lk Inf Al >>> [ 0] NULL 00000000 000000 000000 00 >>> 0 0 0* [ 1] .text PROGBITS 00000000 000034 >>> 000003 00 AX 0 0 1 >>> * [ 2] .data PROGBITS 00000000 000037 000000 00 >>> WA 0 0 1 >>> [ 3] .bss NOBITS 00000000 000037 000000 00 WA >> 0 0 1 >>> [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 000037 000014 00 >> 0 0 1 >>> [ 5] .symtab SYMTAB 00000000 00004c 000060 10 >> 6 6 4 >>> [ 6] .strtab STRTAB 00000000 0000ac 000004 00 >> 0 0 1 >>> [ 7] .shstrtab STRTAB 00000000 0000b0 00003c 00 >> 0 0 1 >>> >>> The .text section is byte-aligned and contains the 3 bytes. >>> >>> Now, I add an instruction to source.s: >>> >>> ; source.s >>> .text >>> .byte 0xff >>> nop >>> .byte 0xff >>> .byte 0xff >>> >>> Looking into the object file, now all of a sudden the .text section is >>> halfword-aligned: >>> >>> There are 8 section headers, starting at offset 0x114: >>> >>> Section Headers: >>> [Nr] Name Type Addr Off Size ES Flg >> Lk Inf Al >>> [ 0] NULL 00000000 000000 000000 00 >>> 0 0 0* [ 1] .text PROGBITS 00000000 000034 >>> 000006 00 AX 0 0 2 >>> * [ 2] .data PROGBITS 00000000 00003a 000000 00 >>> WA 0 0 1 >>> [ 3] .bss NOBITS 00000000 00003a 000000 00 WA >> 0 0 1 >>> [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 00003a 000014 00 >> 0 0 1 >>> [ 5] .symtab SYMTAB 00000000 000050 000080 10 >> 6 8 4 >>> [ 6] .strtab STRTAB 00000000 0000d0 000007 00 >> 0 0 1 >>> [ 7] .shstrtab STRTAB 00000000 0000d7 00003c 00 >> 0 0 1 >>> >>> What is causing the assembler to decide to pad the section in the second >>> case? I am confused because: >>> >>> 1. if the section is .data then the assembler will not pad it anyway, >>> which makes sense, but >>> 2. even if the section is .text, the assembler won't pad it unless it >>> sees an instruction (I can have as many data directives, the section >> won't >>> be padded without having also an instruction), and finally >>> 3. the nop instruction is definitely not aligned and the assembler >> has >>> no problem with it, but it still decides to care about section >> alignment. >>> >>> How is the assembler deciding here to align and pad the section? Can I >>> force the assembler to not pad the .text section even if I have an >>> instruction? >> >> You've told the assembler to interpret the contents of the source file >> as containing thumb instructions. Thumb instructions must be (at least) >> two byte aligned (the fact that your source file deliberately misaligns >> the instruction is a bug in your code). If the section were not aligned >> then the linker would not be able to correctly merge consecutive >> sections if you had a mix of data-only text sections (like your first >> example) and sections containing code. >> >> Note that if you had used -marm instead of -mthumb the alignment would >> be set to 4 as all 'arm' instructions must be 4-byte aligned. >> >> R. >> >> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: arm-none-eabi-as: what decides .text section alignment/padding? 2023-06-19 16:22 ` Richard Earnshaw (lists) @ 2023-06-19 16:39 ` Alexandru Onea 0 siblings, 0 replies; 5+ messages in thread From: Alexandru Onea @ 2023-06-19 16:39 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: binutils [-- Attachment #1: Type: text/plain, Size: 6620 bytes --] I understand that both .text and .data and any other section for that matter will inherit the alignment of the largest element within, however the assembler will apply padding in order to ensure alignment, based on the section flags, for example for sections that are flagged as eXecute. Is my understanding correct? Best regards, Alexandru N. Onea On Mon, 19 Jun 2023 at 19:22, Richard Earnshaw (lists) < Richard.Earnshaw@arm.com> wrote: > On 19/06/2023 17:01, Alexandru Onea via Binutils wrote: > > Therefore, is it that the only difference between the two cases shown in > my > > example boils down to whether the assembler sees an instruction or not? > > I understand it as follows: > > > > Case A: .text section with no instruction within, the assembler says > "this > > monkey asks me to put data in a .text section, whatever, maybe where he > > comes from .text means something else" > > Case B: .text section with data and at least one instruction, the > assembler > > says "this monkey now crosses the line, if he wants instructions, I must > > make sure that at least other .text sections can be merged into it" > > > > So does the assembler assume that if there are no instructions in a .text > > section, maybe it is not actually a .text section in the classical sense? > > Alignment is taken from the most aligned element in the section. It > starts off at byte alignment and if you add an instruction with > half-word alignment (thumb) it gets raised to that. If you add an > instruction with word alignment (arm) it gets raised again. If you add > an alignment directive with even higher alignment then that will > dominate the overall alignment of the section. > > The only difference between this and, say, the .data section is that the > alignment is implied by the instruction rather than explicitly requiring > an alignment directive. > > A final note on this is that a .text section may contain both code and > data. But the two are not the same and the assembler needs to keep > track of them (especially on big-endian systems) so that byte swapping > of instructions can be done correctly at link time. So don't try to > fake up instructions by emitting .byte or similar directives, it will > just lead to silent problems later on - use the .inst directive if you > need to emit an opcode as binary. > > R. > > > > > Best regards, > > Alexandru N. Onea > > > > > > On Mon, 19 Jun 2023 at 16:31, Richard Earnshaw (lists) < > > Richard.Earnshaw@arm.com> wrote: > > > >> On 19/06/2023 08:14, Alexandru Onea via Binutils wrote: > >>> Hello, community! > >>> > >>> I am playing with arm-none-eabi-as trying to understand how it aligns > >>> sections. I have the following source: > >>> > >>> ; source.s > >>> .text > >>> .byte 0xff > >>> .byte 0xff > >>> .byte 0xff > >>> > >>> I am inspecting the resulting object file: > >>> > >>> $ arm-none-eabi-as -mthumb -o source.o source.s > >>> $ arm-none-eabi-readelf -S source.o > >>> There are 8 section headers, starting at offset 0xec: > >>> > >>> Section Headers: > >>> [Nr] Name Type Addr Off Size ES > Flg > >> Lk Inf Al > >>> [ 0] NULL 00000000 000000 000000 00 > >>> 0 0 0* [ 1] .text PROGBITS 00000000 000034 > >>> 000003 00 AX 0 0 1 > >>> * [ 2] .data PROGBITS 00000000 000037 000000 00 > >>> WA 0 0 1 > >>> [ 3] .bss NOBITS 00000000 000037 000000 00 > WA > >> 0 0 1 > >>> [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 000037 000014 00 > >> 0 0 1 > >>> [ 5] .symtab SYMTAB 00000000 00004c 000060 10 > >> 6 6 4 > >>> [ 6] .strtab STRTAB 00000000 0000ac 000004 00 > >> 0 0 1 > >>> [ 7] .shstrtab STRTAB 00000000 0000b0 00003c 00 > >> 0 0 1 > >>> > >>> The .text section is byte-aligned and contains the 3 bytes. > >>> > >>> Now, I add an instruction to source.s: > >>> > >>> ; source.s > >>> .text > >>> .byte 0xff > >>> nop > >>> .byte 0xff > >>> .byte 0xff > >>> > >>> Looking into the object file, now all of a sudden the .text section is > >>> halfword-aligned: > >>> > >>> There are 8 section headers, starting at offset 0x114: > >>> > >>> Section Headers: > >>> [Nr] Name Type Addr Off Size ES > Flg > >> Lk Inf Al > >>> [ 0] NULL 00000000 000000 000000 00 > >>> 0 0 0* [ 1] .text PROGBITS 00000000 000034 > >>> 000006 00 AX 0 0 2 > >>> * [ 2] .data PROGBITS 00000000 00003a 000000 00 > >>> WA 0 0 1 > >>> [ 3] .bss NOBITS 00000000 00003a 000000 00 > WA > >> 0 0 1 > >>> [ 4] .ARM.attributes ARM_ATTRIBUTES 00000000 00003a 000014 00 > >> 0 0 1 > >>> [ 5] .symtab SYMTAB 00000000 000050 000080 10 > >> 6 8 4 > >>> [ 6] .strtab STRTAB 00000000 0000d0 000007 00 > >> 0 0 1 > >>> [ 7] .shstrtab STRTAB 00000000 0000d7 00003c 00 > >> 0 0 1 > >>> > >>> What is causing the assembler to decide to pad the section in the > second > >>> case? I am confused because: > >>> > >>> 1. if the section is .data then the assembler will not pad it > anyway, > >>> which makes sense, but > >>> 2. even if the section is .text, the assembler won't pad it > unless it > >>> sees an instruction (I can have as many data directives, the > section > >> won't > >>> be padded without having also an instruction), and finally > >>> 3. the nop instruction is definitely not aligned and the assembler > >> has > >>> no problem with it, but it still decides to care about section > >> alignment. > >>> > >>> How is the assembler deciding here to align and pad the section? Can I > >>> force the assembler to not pad the .text section even if I have an > >>> instruction? > >> > >> You've told the assembler to interpret the contents of the source file > >> as containing thumb instructions. Thumb instructions must be (at least) > >> two byte aligned (the fact that your source file deliberately misaligns > >> the instruction is a bug in your code). If the section were not aligned > >> then the linker would not be able to correctly merge consecutive > >> sections if you had a mix of data-only text sections (like your first > >> example) and sections containing code. > >> > >> Note that if you had used -marm instead of -mthumb the alignment would > >> be set to 4 as all 'arm' instructions must be 4-byte aligned. > >> > >> R. > >> > >> > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-06-19 16:40 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-06-19 7:14 arm-none-eabi-as: what decides .text section alignment/padding? Alexandru Onea 2023-06-19 13:31 ` Richard Earnshaw (lists) 2023-06-19 16:01 ` Alexandru Onea 2023-06-19 16:22 ` Richard Earnshaw (lists) 2023-06-19 16:39 ` Alexandru Onea
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).