search

DCPUTeam / DCPUToolchain

[ARCHIVED] The code repository for the DCPU-16 Toolchain.
http://dcputoolcha.in/
MIT License
96 stars 14 forks source link

dtld fails with assertion #231

Open SamTechnologeek opened 11 years ago

SamTechnologeek commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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

ghost commented 11 years ago

define big

SamTechnologeek commented 11 years ago

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

hach-que commented 11 years ago

.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 commented 11 years ago

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