#495 Adding linter expressions to obtain the address and size of a section

[Dmitry Panin]

The linker doesn't have a simple way to specify the order of sections so they appear sequentially (for example, DATA after CODE).

Extension makes this easy by adding a couple of commands to the expressions.

It looks something like this:

-b _HEADER = 0x8000
-b _CODE = $START(_HEADER) + $SIZE(_HEADER)
-b _DATA = $START(_CODE) + $SIZE(_CODE)

or through sdcc flags:

-Wl "-b _HEADER = 0x8000" -Wl "-b _CODE = $START(_HEADER) + $SIZE(_HEADER)" -Wl "-b _DATA = $START(_CODE) + $SIZE(_CODE)"

[Janko Stamenović]

Thanks. It's definitely an interesting approach, and as far as I know, currently missing functionality.

The use of $ inside of the " quoted strings probably not the best idea anywhere outside of Windows hosts. I'd maybe use .start and .size instead, but I think it wouldn't be bad idea otherwise. The longer term potential problem is that the wish is to achieve less differences to the upstream, and upstream now has more complex handling of these.

[Dmitry Panin]

Thanks for the review; these are very valuable comments.

Of course, the choice of naming for linter commands is entirely up to the maintainers. Other commands may appear in the future, so this issue needs to be carefully considered in advance.

Attached are two additional patches for discussion: one with a dot (.START .SIZE) and one that treats the command as a regular START SIZE (-b _DATA = START(_CODE) + SIZE(_CODE)), but only if there's no such symbol in the files. This will allow the changes to be implemented with minimal impact.

[Philipp Klaus Krause]

Since sdld is a fork of the linker from upstream asxxxx: is there similar functionality in upstream asxxxx, that we could use?

[Dmitry Panin]

I may be wrong, but I haven't found anything like this in the documentation or source files of the latest versions of asxxxx

[Janko Stamenović]

My initial comment was just from the "outside" perspective (as a user, without looking in the sources). Looking in the sources and upstream sources: your patch modifies the linker's expression evaluator, which in upstream does introduce the use of '$' (documented in the manual as "Temporary Radix Operators" (Table 6)). Also checking, in the assembler $, . and _ are all a valid part part of the symbol name. So even my dot suggestion is probably too simple to be the safe solution? I'm still not sure. Your idea could simplify some real life scenarios, if it would be certain that it fits with the rest of the existing and planned infrastructure and can't cause clash with actual uses and planned development, so I think we should first learn more what the potential impact of such a change could be. Maybe we will be eventually (it could take time!) able to get the comments from the upstream author of how such modification would be able to be implemented to match all the development goals.