Workaround for crtbegin.o or crtend.o not being included into the link

[kib]

Summary

crtbegin: accurately check for the end of .dtors

not relying only on the end section marker, but also checking for the
section size when iterating.

Reported by:    kargl
Analyzed by:    dim

crtbegin: accurately check for the start of .ctors

For the hypothetic situation where crtbegin.o is not linked into the
binary, but crtend.o is, which results in the missing starting sentinel
in the ctors array, be careful to not iterate past the start of the
section.

[dim]

LGTM

lib/csu/common/crtbegin.c

88–89

So we expect that if .dtors is nonexistent, that both startof and sizeof are zero?

[kib]

lib/csu/common/crtbegin.c

88–89

They are weak. Why the question?

[dim]

lib/csu/common/crtbegin.c

88–89

I was just wondering what would happen if one of them was zero, but the other wasn't. But that is probably extremely unlikely. :)

[kib]

lib/csu/common/crtbegin.c

88–89

I added the zero check to work around a possible case that linker does not support these .startof. and .sizeof. symbols. We do always have the .dtors section if this file is ever compiled/linked.

[andrew]

How difficult would it be to write a test for this?

[kib]

In D48700#1110954, @andrew wrote:

How difficult would it be to write a test for this?

It is relatively cumbersome. The mock for crtbegin and crtend would need to be provided, containing everything but the CTOR_LIST and DTOR_END elements. I.e. it would need to make a copy of the current .c files, and then explicitly write out linker invocation to use that instead of csu from /usr/lib.

[andrew]

We might be able to use objcopy to remove them from the existing binary, but the test shouldn't block a fix.