This change seems to have also regressed code like this:

I'm totally fine with specifying a mostly-linear ordering between sections, including between custom sections that are meaningful to the toolchain. But I think it also makes sense to allow for exceptions to that when it allows for simpler code, as is the case for the unspecified ordering between the producers section and relocation sections. This CL is about changing the mechanism to allow for this exception, not about changing the ordering of existing sections or changing our norm of specifying such orderings. Do you think we should disallow exceptions entirely?

In D58312#1402909, @tlively wrote:

In D58312#1402683, @binji wrote:

Yeah, I'd still prefer to have a total order if that's not too much effort. The alternative introduces a lot of potential complexity into the consumer, since we'll have a combinatorial explosion of possibilities for where these sections can be located, many of which will likely be untested.

I definitely want to reduce overall complexity, not increase it. My assumption is that if consumer code would be simplified by guaranteeing that section A is before section B, then the DAG ordering should be updated to make that ordering required. Sections should only be unordered with respect to each other if consumers are truly agnostic to their order.

In this case, producer code was able to be simplified by loosening the ordering constraints with no corresponding complications in consumer code that I am aware of. @binji, does this seem reasonable? Are there potential complications that I am missing?

Yeah, I'd still prefer to have a total order if that's not too much effort. The alternative introduces a lot of potential complexity into the consumer, since we'll have a combinatorial explosion of possibilities for where these sections can be located, many of which will likely be untested.

lgtm

lgtm