Bug 168

Created attachment 146 [details]
Should fix things up

Hi there,

You forgot to specify the most important bit - what should the two fields contain if the file does not have any debug symbols! I took a wild stab and assumed that both should be zero.

In this case, the attached patch should fix things up.

I also took the opportunity to reduce console spam. The offending message should now only show up with debugging level 2 (-v -v).

Thank you for the patch.

I didn't know what the two fields should contain if the file does not have any debug symbols. You guess to set fields to 0 makes sense to me as well.

After reading your comment, I've found this in an old Microsoft documentation:
"PointerToSymbolTable is the file offset of the COFF symbol table, or zero if no COFF symbol table is present."; so the number of symbols should follow the rule as well: no symbol table, so the number of symbols can be considered as 0 as well.

After applying your patch, I got the folliwing:
PSymbolTable field (offset $8) is now set to 0.
NumberOfSymbols field (offset $c) still contains the number of symbols.

I do beg your pardon, but how exactly are you invoking rln? Here's the invocations I tried and they all work as expected:

Firstly, not asking for any debug symbols to be generated:
rln -v -v -e -rq -o my.bin -a 4000 x x my.o
This produces a binary with zeros in both PSymbolTable and NumberOfSymbols fields.


Asking for all local symbols to be included
rln -l -v -v -e -rq -o my.bin -a 4000 x x my.o
Here I get non-zero values in PSymbolTable and NumberOfSymbols, they seem reasonable. Also I get tons of console spam as the linker adds the symbols before doing the relocations


Lastly, asking for global symbols only to be included
rln -s -v -v -e -rq -o my.bin -a 4000 x x my.o
Same deal, non-zero values in PSymbolTable and NumberOfSymbols, they seem fine.


-e is the switch that requests an absolute COFF file to be generated. So I'm curious to see what you do and get issues.

My patched version of rln shows V1.6.4.
I have checked my rln.c and it shows the patch differences.
I use the u235se-0.24 package to handle my test using rmac V2.0.4.
In case of, could you point me to your current rln source package?

To generate a no debug symbols, I use the following:
rln -v -e -w -rq -o main -a 4000 x x main.o dsp.obj
In this case, I have the following results:
The symbol table value is set to 0.
The number of symbols value is set to $86.

To include debug symbols, I use the following:
rln -v -e -w -s -rq -o main -a 4000 x x main.o dsp.obj
In this case, both fields set values and they look fine to me.

If I use your options:
rln -v -v -e -rq -o main -a 4000 x x main.o dsp.obj
I got an error message "TO DO: Relocatable linking".

Created attachment 147 [details]
Better this time

Okay, so apparently I was testing a object file that didn't have global symbols exported so it worked fine. Not so with the u-235 codebase.

I attached a replacement patch, please try this out and let us know if it works ok.

It works now, I'm able to see both fields set to 0.

However, for your information, if I use your options:
rln -v -v -e -rq -o main -a 4000 x x main.o dsp.obj
I still get the same error message "TO DO: Relocatable linking".

Well, I don't. And you shouldn't either.

This message is only displayed if you don't pass the -a flag. So you're either not passing it or perhaps something is clobbering RAM, maybe a memory leak?

Just to be extra paranoid I ran rln under valgrind and drmemory with the parameters that trigger the error for you. No leaks were found.

So... I don't really know.

Thank you for the fixes.

If a day I gather more information about the error message, I will create a specific bug entry.