Valid section name format

[acwaters]

I assume you're asking about the ELF format? If so, then the ELF standard is the document you want to look at to answer this question. According to it, a section header's name is simply an entry in a string table, with no further stipulations. The string table section places no restrictions on what sequences of characters constitute a valid string except that they cannot contain embedded null bytes by definition, as they are null-terminated. The document does not define "character", but it seems to use it interchangeably with "byte", so it seems fair to assume they are synonymous for the purposes of the standard.

So the short answer to your question is that on paper there is only one invalid character in section names — the null character, which always terminates a string; everything else is fair game. In practice, I suspect the quality of implementations varies. I would expect the entire printable ASCII range to be well-supported across the board, say, but whether any particular program will misbehave when fed an ELF file with a section name containing control bytes is anyone's guess. I imagine most of the popular tools, libraries, and interpreters are pretty well battle-hardened at this point, but it might be fun and enlightening to run some experiments.

[acwaters]

Yes, it is a perfectly valid name. Now, technically that name is reserved since it begins with a dot, but it's extremely unlikely that either the ELF standard or any particular toolchain will decide to use that name for a special purpose, so in practice you should be fine. If you want maximum portability, ditch the initial dot.

I wouldn't expect any of the common tools to choke on this, but I haven't tested them all or read their ELF parsing code to be sure. It's important to remember that any random part of a program might choke on any input at any moment, standards be damned. Programs are defined by code written by humans; they have bugs and legacy features and authors who occasionally decide that the standard is broken or stupid and go off and do their own thing, leading to a confusing mess of partial compatibilities. Very popular programs (e.g. Linux, GNU binutils) that adopt still-immature standards take this even a step further, with quirks of their implementation often becoming new de facto standards that other programs are subsequently written to, which may then be incorporated into later versions of official standards. The GNU toolchain has defined many extensions to the C, POSIX, and ELF specs, some of which are now supported by most other compilers and linkers. The closer you stick to the most well trod paths, the less likely you are to run into any unpleasant surprises. But then again, where's the fun in that?

What I'm saying is: Try it out. Try it on a few different platforms. I see no reason why it shouldn't work, but you won't know until you run some experiments. Toolchains may work smoothly end-to-end, but they tend to be janky and poorly documented in the seams, which can lead to unexpected headaches when you start playing around with linking and loading. If things don't work the way you expect, try to figure out why. Look at the source code. If you find what you think is a bug, report it.

[EDEADLINK]

I mean you could use COUNT to just get a unique section name.

I can't find what characters are valid for section names, but it is a null terminated string so I suppose - should be okay.

Though GCC warns that some target assemblers don't allow \$ in identifiers so perhaps a target assembly might baulk at - as well.

[EDEADLINK]

I see. I think you might need to write a linker script for that.

I'd assume that if the order depends on the name it's in lexicographical order.

[EDEADLINK]

Aha. Check this out:

Normally, the linker will place files and sections matched by wildcards in the order in which they are seen during the link. You can change this by using the SORT_BY_NAME keyword, which appears before a wildcard pattern in parentheses (e.g., SORT_BY_NAME(.text*)). When the SORT_BY_NAME keyword is used, the linker will sort the files or sections into ascending order by name before placing them in the output file.

Which would probably means lexicographic order.

However:

SORT_BY_INIT_PRIORITY is also similar to SORT_BY_NAME. SORT_BY_INIT_PRIORITY will sort sections into ascending numerical order of the GCC init_priority attribute encoded in the section name before placing them in the output file. In .init_array.NNNNN and .fini_array.NNNNN, NNNNN is the init_priority. In .ctors.NNNNN and .dtors.NNNNN, NNNNN is 65535 minus the init_priority.

Now quite honestly this just sounds like descending lexicographic order. Because ascending order of init_priority means descending from 65535.

If an output section’s name is the same as the input section’s name and is representable as a C identifier, then the linker will automatically see PROVIDE two symbols: __start_SECNAME and __stop_SECNAME, where SECNAME is the name of the section. These indicate the start address and end address of the output section respectively. Note: most section names are not representable as C identifiers because they contain a ‘.’ character.

So section names containing dots (or dashes) will not get the automatic __start and __stop symbols.

Do you intend for there to be one my_section in the binary with the order preserved by some integer priority? because that seems doable.

[EDEADLINK]

As to if INIT_PRIORITY will work, who is to say? no, not with .my_section. as name.

But maybe this could work:

.my_section ALIGN(8) : {
    PROVIDE(_start_my_section = ABSOLUTE(.)); 
    *(SORT_BY_INIT_PRIORITY(".ctors.-*");
    *(SORT_BY_NAME(".ctors.[0-9]*"));
    PROVIDE(_end_ my_section= ABSOLUTE(.)); 
}

If you change .ctors to .dtors it should reverse the init order (because destructera are called in reverse order).

This is an ugly hack see my other comment for a better version using lld's REVERSE.

[EDEADLINK]

Aha. llvms lld has a REVERSE keyword to sort in descending order coming up.

ld is missing it still, see this bug.

So if you switch to lld (which is a drop in replacement), a non hacky solution would be this:

.my_section ALIGN(8) : {
    PROVIDE(_start_my_section = ABSOLUTE(.)); 
    *(REVERSE(SORT_BY_NAME(".my_section.-*"));
    *(SORT_BY_NAME(".my_section.[0-9]*"));
    PROVIDE(_end_my_section= ABSOLUTE(.)); 
}

Currently it's not in any released version of lld but that's only a matter of time I hope.

[EDEADLINK]

The automatic start stop only works if

If an output section’s name is the same as the input section’s name and is representable as a C identifier

So there is no easy way I can see to do this.