dtld fails with assertion

[SamTechnologeek]

dtld fails with message:

dtld: /home/buildbot/bot/slave/stable_linux/build/libdcpu-ld/ldbins.c:84: bin_print: Assertion `list_get_at(&bin->words, entry->address) != ((void *)0)' failed.

I don't have any idea why, although I've noticed it happens when 2 files are used to generated a binary, and one has an .export directive, the other one an .import directive, and they are both big files; if the files are small it doesn't happen.

Cheers,
Sam.

[ghost]

Does this occur only with certain files? Or in every situation in which "2 files are used to generated a binary, and one has an .export directive, the other one an .import directive, and they are both big files"?

[SamTechnologeek]

Every situation in which more than 1 file is given to dtld and are big.

[ghost]

define big

[SamTechnologeek]

I investigated a bit: forget the 2 files or more, or big files or anything: it's .org which crashes it.

[hach-que]

.ORG is a bit weird in that it pretends that code is at a particular offset when it isn't. It's important to note that because it doesn't relocate or move the code at compile time, and all it does is change the offsets, that the code emitted is not valid until you move it a runtime. Normal execution of that code is not possible.

Most often .ORG is used to relocate code so that it can run against a kernel, where the kernel requires that the code is already adjusted ahead of time. The default kernel, "stubsys" requires exactly that. However, the linker now plays the role of aligning code against the kernel, it's not up to the application developer to do that. When you link your application against a kernel, it will read the kernel's policy file and automatically perform these kind of manipulations based on what the kernel requires. Effectively, it modifies your code to run against any kind of kernel, without having to design your application to specifically support it.

I can't really see much of a use case for .ORG when linking against a kernel; you're going to be producing invalid code (which the linker will not correct and in most cases, you'll get a double offsetting effect as the linker can only relatively add or subtract positioning information). This is the reason that .ORG under the toolchain produces a warning; it's only suitable use is when you don't have a linker to perform these operations for you.

If you're linking against a kernel that needs applications to be placed at a given offset, I recommend taking a look at the linker policy used for stubsys and creating one for the kernel in question. Send it back to us, and we'll include it main distribution.

[SamTechnologeek]

@hach-que thanks for the explanation :) but the problem is still there: dtld crashes if you use .ORG