[z88dk-dev] [z80asm] bugs with sym files

[alvin]

I've found a couple of issues with the symbol files z80asm is producing:

1. z80asm seems to be pruning the sym file and the map file so that unused constants are removed.

As an example, this is generated in zcc_opt.def:

IF !DEFINED_SDSC_HDR_DATE
defc DEFINED_SDSC_HDR_DATE = 1
defc SDSC_HDR_DATE = 20160131
ENDIF

The symbol file contains this:
DEFINED_SDSC_HDR_DATE = $0001 ; L

The map file contains this:
DEFINED_SDSC_HDR_DATE = $0001 ; L zccF4BA3

Neither contains any definition of "SDSC_HDR_DATE" and I think it's because "SDSC_HDR_DATE" is never actually used in the source. This value is communicated to appmake after the program is linked so it's still needed.

2. The sym file contains pre-link values for defined constants.

An example:

Inside the sym file:
SDSC_HDR_AUTHOR = $0000 ; G

Inside the map file:
SDSC_HDR_AUTHOR = $0811 ; G zccF4BA3

This constant is defined with this:

IF !DEFINED_SDSC_HDR_AUTHOR
PUBLIC SDSC_HDR_AUTHOR
EXTERN _author
defc DEFINED_SDSC_HDR_AUTHOR = 1
defc SDSC_HDR_AUTHOR = _author
ENDIF

The symbol "_author" is the address of a char array defined in C, so the address must be filled in at the linking step.



------------------------------------------------------------------------------

[pscust]

1. z80asm seems to be pruning the sym file and the map file so that

unused constants are removed

This is by design but I do not know the reason. Probably the idea was not
to pollute the object files with symbols that were defined but not used.
z80asm collects all defined symbols, marks all that are used in any
expression and only dumps the marked ones to the object file.

I can try to remove the check and see the impact.

2. The sym file contains pre-link values for defined constants.

This is by design. The sym file is generated at the end of the assembly
process and outputs information as available in the object file. At this
time, all the addresses are zero-based.

The map file is generated at the end of the link process and has all the
addresses resolved.

Is the sym file useful? Or should we just drop it?



On Tue, Aug 23, 2016 at 8:17 AM, alvin (alvin_albrecht@...) <
lists@...> wrote:

I've found a couple of issues with the symbol files z80asm is producing:

1. z80asm seems to be pruning the sym file and the map file so that
unused constants are removed.

As an example, this is generated in zcc_opt.def:

IF !DEFINED_SDSC_HDR_DATE
defc DEFINED_SDSC_HDR_DATE = 1
defc SDSC_HDR_DATE = 20160131
ENDIF

The symbol file contains this:
DEFINED_SDSC_HDR_DATE = $0001 ; L

The map file contains this:
DEFINED_SDSC_HDR_DATE = $0001 ; L zccF4BA3

Neither contains any definition of "SDSC_HDR_DATE" and I think it's
because "SDSC_HDR_DATE" is never actually used in the source. This value
is communicated to appmake after the program is linked so it's still needed.

2. The sym file contains pre-link values for defined constants.

An example:

Inside the sym file:
SDSC_HDR_AUTHOR = $0000 ; G

Inside the map file:
SDSC_HDR_AUTHOR = $0811 ; G zccF4BA3

This constant is defined with this:

IF !DEFINED_SDSC_HDR_AUTHOR
PUBLIC SDSC_HDR_AUTHOR
EXTERN _author
defc DEFINED_SDSC_HDR_AUTHOR = 1
defc SDSC_HDR_AUTHOR = _author
ENDIF

The symbol "_author" is the address of a char array defined in C, so the
address must be filled in at the linking step.



------------------------------------------------------------
------------------

[alvin]

I'm not sure why these responses are not being picked up by the forum but I've included it below for archiving.

Is the sym file useful? I can imagine it might be. The main thing is appmake searches the crt's sym file for defined constants that indicate features. The preference for using the sym file is because it's much shorter than the map file. One particular target might look for 3 or 4 constants while building the output file and that's done separately for each constant (open file, read lines sequentially, match against constant name). I don't know if performance is hit too badly if the map file is searched instead, not to mention we would have to qualify the symbol definitions to make sure it comes from the crt file and not some other user file. Besides that I may have to look in the map file for some things (post-linked values) anyway and I think maybe the z88 target might be doing that already as it must find out how big some sections area (I think). I'll look at this later today.

About the symbol pruning... that might be desirable in most cases but definitely we need to propagate some unused definitions coming from pragmas (they occur in DEFINED_SYMBOL / SYMBOL pairs). Without the pruning there could be a very large number of symbols defined in each module (module may include a def constants file for things like stdio messages that are unused by an individual file).

Short on time atm so I'll just post this now.

1. z80asm seems to be pruning the sym file and the map file so that unused constants are removed

This is by design but I do not know the reason. Probably the idea was not to pollute the object files with symbols that were defined but not used. z80asm collects all defined symbols, marks all that are used in any expression and only dumps the marked ones to the object file.

I can try to remove the check and see the impact.

2. The sym file contains pre-link values for defined constants.

This is by design. The sym file is generated at the end of the assembly process and outputs information as available in the object file. At this time, all the addresses are zero-based.

The map file is generated at the end of the link process and has all the addresses resolved.

Is the sym file useful? Or should we just drop it?

------------------------------------------------------------------------------

[alvin]

1. z80asm seems to be pruning the sym file and the map file so that unused constants are removed

This is by design but I do not know the reason. Probably the idea was not to pollute the object files with symbols that were defined but not used. z80asm collects all defined symbols, marks all that are used in any expression and only dumps the marked ones to the object file.

I can try to remove the check and see the impact.

I think we should leave it as is. In the c lib a lot of source files include a common file containing defined constants, many of which will not be referenced. If the unreferenced constants are not pruned the map/sym file will include many copies of those constants for each file that includes them. I can imagine this will be the case for any large project.

What I did instead is generate a reference to the symbols that need to be passed on to appmake.

Before:

IF !DEFINED_SDSC_HDR_DATE
defc DEFINED_SDSC_HDR_DATE = 1
defc SDSC_HDR_DATE = 20160131
ENDIF
ENDIF

After:

IF !DEFINED_SDSC_HDR_DATE
defc DEFINED_SDSC_HDR_DATE = 1
defc SDSC_HDR_DATE = 20160131
IFNDEF SDSC_HDR_DATE
ENDIF
ENDIF

Whereas "SDSC_HDR_DATE" was being pruned in the before case, it is no longer in the after case.

2. The sym file contains pre-link values for defined constants.

This is by design. The sym file is generated at the end of the assembly process and outputs information as available in the object file. At this time, all the addresses are zero-based.

The map file is generated at the end of the link process and has all the addresses resolved.

Is the sym file useful? Or should we just drop it?

zcc will now always generate a map file as well as the sym file when -create-app is used. For constants whose final values must be determined by the linker, I look through the map file instead of the sym file. So that problem is solved as well.

The sym file makes it easier to find constants defined in the crt by the toolchain without having to exclude user symbols of the same name defined in other source files. It's also smaller so searches should be faster... so it's still useful.



------------------------------------------------------------------------------