This shows you the differences between two versions of the page.
— |
blog:pushbx:2023:0924_mid_september_work_on_toclip_warplink_ldebug [2023-09-24 18:59:06 +0200 Sep Sun] (current) ecm created |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Mid September work on toclip, WarpLink, lDebug ====== | ||
+ | |||
+ | |||
+ | **2023-09-24** | ||
+ | |||
+ | Last week on Sunday I was occupied with something other than preparing a blog post. Therefore, today I will cover the changes since two weeks ago. | ||
+ | |||
+ | |||
+ | ===== toclip ===== | ||
+ | |||
+ | The toclip application got [[https:// | ||
+ | |||
+ | The application was also added to the current release builds built by the wwwecm scripts. | ||
+ | |||
+ | |||
+ | ===== WarpLink ===== | ||
+ | |||
+ | During an audit of the ported WarpLink sources, I noticed that two spots used two-byte text literals as instruction operands. These are interpreted differently by NASM and TASM. While adding the conversion to the '' | ||
+ | |||
+ | Another change concerns the '' | ||
+ | |||
+ | |||
+ | ===== lDebug ===== | ||
+ | |||
+ | ==== Various ==== | ||
+ | |||
+ | * Fix minor bug (no ill effects), [[https:// | ||
+ | * Add /TX, /TY, and /TZ switches [[https:// | ||
+ | * Add missing '' | ||
+ | * [[https:// | ||
+ | * In '' | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * Help: [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | ==== Extensions for lDebug ==== | ||
+ | |||
+ | The big change this week is basic support for loading plugin executables stored in Extension for lDebug (.ELD) files. | ||
+ | |||
+ | The ELD architecture supplies an ELD with three structures: | ||
+ | |||
+ | * The ELD instance part. This is typically initialised to the ELD code section. Currently stored in a separate segment by the debugger, Protected Mode operation provides both a code selector and a data selector for this segment. | ||
+ | * The ELD data block. This can be initialised to the ELD data section. It is allocated within the debugger data/entry section. | ||
+ | * The link info. This provides tables that associate label names of data items, entry code, code1, or code2 functions with the corresponding addresses. | ||
+ | |||
+ | The idea is that the ELD carries a linker, which can be discarded once it has successfully run. The linker uses tables in the ELD as well as the debugger' | ||
+ | |||
+ | * Internal code to code relocations (fix offsets in ELD code instance to refer to the code instance where it is actually loaded) | ||
+ | * Internal code to data relocations (fix offsets in ELD code instance to refer to the ELD data block) | ||
+ | * Internal data to code relocations (fix offsets in ELD data block to refer to the ELD code instance) | ||
+ | * Internal data to data relocations (fix offsets in ELD data block to refer to the data block) | ||
+ | * Data link relocations in ELD code instance (refer to debugger data label in ELD code) | ||
+ | * Data link relocations in ELD data block | ||
+ | * Code link relocations from ELD code instance to one of three debugger code sections | ||
+ | |||
+ | Data link relocations can be optional: If an optional data link relocation is not found, the linker fills it with a zero word instead. | ||
+ | |||
+ | Code link relocations can refer to the code1 section, the code2 section, or the entry section of the debugger. The linker expands a code link relocation into a near call into the LINKCALL default ELD, to an entrypoint which will handle the setup of a far call into the corresponding section. The called function gets a near call return address which leads to an ext call return handler. This is simply a '' | ||
+ | |||
+ | The ext (code) segment can be any size from 0 Bytes to 65_520 Bytes. The default is 8 KiB for application or device mode, and 16 KiB for bootloaded mode. Non-bootloaded modes allow specifying an /X= switch to change the size at init time. The initial memory allocation for application and device mode assumes the maximum ext segment size. | ||
+ | |||
+ | The ELD data blocks space currently defaults to 16 KiB. As it resides within the data entry section, it cannot be resized. (I am considering to move it back past the stack, so it would occupy the tail end of the data entry section. This would allow to resize it in the init.) | ||
+ | |||
+ | The ELD link info currently takes less than 2 KiB. It is stored in the debugger' | ||
+ | |||
+ | The ELD linker and associated data tables in the ldmem.eld example takes up about 1.1 KiB. It is important to recall that the linker must be included in any (nontrivial) ELD, so its size must be added to every ELD's own size. This approach was chosen to avoid a resident linker in the debugger code section, presumably saving some 500 to 1000 Bytes. | ||
+ | |||
+ | When an ELD unloads itself, it is responsible for decrementing the ELD code segment and ELD data block space " | ||
+ | |||
+ | Basic linking and use of debugger functions and data structures is implemented. This is enough to implement a number of "one shot" ELDs, such as the ldmem.eld which displays information on the debugger' | ||
+ | |||
+ | |||
+ | === ldmem.eld === | ||
+ | |||
+ | The first really useful ELD is ldmem.eld, the lDebug memory use display ELD. For now, it detects all sections used by the main debugger (not including symbol tables) as well as gaps between them in the debugger allocation. It also sorts all the sections in order of increasing addresses, a feature I have long missed in the RVM command. | ||
+ | |||
+ | This ELD is far from complete however. | ||
+ | |||
+ | |||
+ | === Inclusion in builds === | ||
+ | |||
+ | For now, the ELD interfaces and buffers are not included in default builds of the debugger. The _EXTENSIONS build option needs to be specified for including ELD support. Presumably once the ELD infrastructure is more complete, and before the next release (release 7), the build option will be enabled by default. | ||
+ | |||
+ | {{tag> | ||
+ | |||
+ | |||
+ | ~~DISCUSSION~~ | ||