Bug 168 - COFF symbol table fields wrongly set
Summary: COFF symbol table fields wrongly set
Status: UNCONFIRMED
Alias: None
Product: RLN
Classification: Unclassified
Component: Core (show other bugs)
Version: unspecified
Hardware: PC Windows
: Normal normal
Assignee: Shamus Hammons
URL:
Depends on:
Blocks:
 
Reported: 2020-07-29 16:48 CDT by djipi.mari
Modified: 2020-09-02 01:33 CDT (History)
2 users (show)

See Also:


Attachments
Should fix things up (2.41 KB, patch)
2020-09-01 10:02 CDT, ggn
Details
Better this time (2.43 KB, patch)
2020-09-01 16:19 CDT, ggn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description djipi.mari 2020-07-29 16:48:57 CDT
If the options related to symbols are not used, the PSymbolTable and NumberOfSymbols fields in the coff will still be set. It will, or may, create a problem if the fields are used by a tool or a debugger, because no symbols will be found in the file.

Repro steps:
1) Assemble any kind of source file with rmac
2) Link the object file without symbol related option
3) Notice the size of the coff file
4) Open the coff file with a hex editor and look at the 0x8 & 0xc offsets
5) Notice the 0x8 offset value points to the end of the file
Comment 1 ggn 2020-09-01 10:02:10 CDT
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).
Comment 2 djipi.mari 2020-09-01 13:55:54 CDT
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.
Comment 3 ggn 2020-09-01 14:19:37 CDT
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.
Comment 4 djipi.mari 2020-09-01 15:27:31 CDT
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".
Comment 5 ggn 2020-09-01 16:19:30 CDT
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.
Comment 6 djipi.mari 2020-09-01 16:44:23 CDT
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".
Comment 7 ggn 2020-09-02 01:28:14 CDT
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.
Comment 8 djipi.mari 2020-09-02 01:33:50 CDT
Thank you for the fixes.

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