First of all thanks for contributing to cc65 in general - and for the verbose comment in particular :-)

Regarding the tests:

Maybe I'm missing the point but I image something like three source files:

1. Export weak symbol 'a' with value 1.
2. Export weak symbol 'b' with value 2.
3. Export "normal" symbol 'b' with value 3.

Then have a source file importing 'a' and 'b' and check that their values are 1 and 3.

Another test would be to create an object file which uses a weak symbol. Create another object file which has implementation for this symbol and put it into a lib. Link the first object file with the lib. The unresolved weak symbol shouldn't cause the object file from the lib being pulled in.

Yes - so it seems one can test this well enough in a black box fashion. Not looking into the actual generated content, but check if the content behaves as expected.

I addressed the minor styling issues. I don't know if force-pushing the PR is good etiquette; I wanted to avoid adding more commits, but I actually manage to mess it up the first time, so please compare the last head with a92c120 to see clearly what changed.

Regarding the testing issue: I think I understand how I can test it, and that is by using link time assertions. I saw there's a binary diff tool in test, so yet another way to test would be to generate a binary file and compare to some reference output. All those solutions are more portable that the one I initially thought, that is using awk to check the map file. But here the other problem: all the other tests are simples, one file tests and unless I'm mistaken, all the Makefiles are designed to map exactly one source file per test. Here I want to test the linker with several input files. Do I create a new directory in test and do a different, tailored Makefile for that scenario?

Sorry but I didn't look closely enough at the existing test infrastructure before commenting on the test topic. We have:

1. test/ref: This is about C code which is run and has its output compared to a reference.
2. test/asm: This is about asm code which is assemblered and has its object file compared to a reference.

One can argue that 2.) is suboptimal because it would be preferable if it would rather "somehow" work on assembler listing files, but that's not our point here.

So presuming we don't want to set up a new test infrastructure it's pretty clear that 1.) is no option as it's about C code. For sure 2.) isn't a perfect test as it doesn't test the linker in any way but it's better than nothing. I suggest to add a/vew tests to 2.) just checking if the assembler honors the new directive.

Note: In case you WANT to add "better" testing and have the problem of the tests being "single source file" you could likely workaround it by employing the runtime/C library:

Look e.g. at https://github.com/cc65/cc65/blob/master/libsrc/common/atoi.s - there are the two exports _atoi and _atol. If you make your single source import _atoi, then the linker is urged to make that module part of the binary. If you now declare _atol as weak you should trigger the code paths in question your want to test, don't you?

You confirmed what I observed WRT how the existing tests work.

However, your last suggestion is interesting. Basically, I can make a assembly file import _atos, then define a weak symbol _atoi, and verify that _atoi = _atos even though I defined _atoi to be another value? That would be easy to do.

[...] That would be easy to do.

Yep. If nobody else has another idea that can be realized with appropriate amount of effort I suggest to do just that (with a reasonable amount of inline documentation how this test works and what assumptions regarding the C library the test makes) and we'll have this PR merged.

That's a good idea. I didn't write the test case yet, I manually just tried the idea and worked good. Except!.. 1) there's a bug in the feature where a "redundant" .export somehow clears the WEAK flag of the symbol (I didn't look hard enough into .import and .export I guess), and 2) my first force-push was really borked and there is still a change I missed and overwrote. I learned my lesson: I'll add more commits for the future fixes rather than risking another borked force-push into this PR.

EDIT: I think a test like this (but with more generous comments) is sufficient:

    .import _atoi
    .weak _atol

    .global _main

    .code
_atol := 23 ; dummy assignment, so the symbol is marked as an export
    jsr _atoi
    .assert _atol = _atoi, lderror, "weak feature failure: symbol not overridden" 

_main:
    rts

So I check that the _atol is overridden by a .assert at link time, does that look good? As I said, I'll add more comments and also I need a test case for the bug I still have.

Thanks for the intermediate feedback. From what I understand you're on the right track :-)

Any news?

June was a quite busy month and I am still in the process of moving in with my gf; still in boxes and the computer desk isn't even set up... :/ I'll be back soon!

Whats the status of this?

One thing i'd really like to see added, is some simple test program that not only tests and demonstrates this feature - but which also could be referenced from the documentation

Well, I wrote some test code and it only partly works. Specifically, it doesn't work if you define a weak symbol and want it to be overridden by a library symbol by referencing a related symbol.

I also realized that by itself, this feature is not that interesting because in order to save memory when redefining a weak symbol, the linker should have some sort of garbage collector that detect code/data sections that are not referenced anymore.

I honestly did lose a bit of motivation because of this, and also because of other life events that happened meanwhile.

Converting this to draft - it seems not ready for merge