Relinking executables with VLINK
I've had fun writing loaders for both standard Amiga Hunk loadfiles, and vlink's rawseg (-q) format. The rawseg loader is considerably more straightforward and efficient - it's a great format which I would prefer to use wherever possible.
When I'm working with my own code, I can easily assemble source and link to rawseg binaries, but obviously most pre-existing (third party) executables are in hunk format. I thought it might be possible to use vlink to convert a hunk executable into rawseg format, so I threw phx's linker script at it to see what happened. Code:
PHDRS { Code:
vasmm68k_mot -Fhunkexe -kick1hunks -no-opt -nosym -wfail -o intermediates\loadfile loadfile.asm Code:
Warning 12: "loadfile" is already an executable file. Is Warning 12: "loadfile" is already an executable file. really just a warning? Is it saying "processing an executable is not possible" or "just to let you know that this is a loadfile, not an object file, but I can still proceed"? Would it be possible to modify the linker script to work from section types rather than names to make this work? Again, I really don't *need* this, just thought it would be nice to use the linker to do the job rather than perhaps considering a custom tool at some point. |
Quote:
Quote:
Quote:
Quote:
*(S*)in your script, which merges all sections from the executable into a single output section. Not really what you want, I guess. ;) Maybe I should improve that section naming, by including the type into the unique name, like "CODE1234", "DATA1234", etc.? I can check that. |
This sounds very encouraging thanks.
Would if be enough for the generated section name to contain the initial hunk type (CODE, DATA, BSS) and the memory flags (ANY, FAST, CHIP, CUSTOM) For example: "CODE_ANY_0", "DATA_CHIP_0", "DATA_CHIP_1", "BSS_ANY_0", "DATA_CUSTOM7890ABCD_0" Then the .ld section name wildcards should be able to match. |
You're absolutely right! The memory flags should be included into the auto-generated name, because this is the only way a linker script could see them.
The solution, which I just committed (available with tomorrow's daily source snapshot), is to use "code", "data" and "bss" for the type. Followed by an optional memory attribute "chip" or "fast". Which may be followed by an index, starting with "0001", when there are more than one section of a type. BTW, yesterday I forgot that you can already assign names for different section types with the current version of vlink, when using the -fixunnamedoption. Disadvantage is that multiple sections of the same type would then be merged, and memory flags are still missing (also fixed with tomorrow's update). |
That's amazing thanks. I'll look forward to trying this out.
|
Quote:
|
Quote:
Updated linker script: Code:
PHDRS { Code:
SECTION code,code ; name: "code", sec_type: code, mem_type: not specified (either chip or fast will do) Code:
SETLOCAL It is far more flexibile not having to stick to a naming convention for sections e.g. "chipmem" from original linker script. Can now just revert to using arbitrary names SECTION bss_c,bss,chip or SECTION data_c,data,chip. Should make large projects easier to manage. (I thought it wasn't working at first, but embarssingly I thought that syntax such as SECTION data_c implied SECTION data_c,data_c). The relinking command in my build script now uses -nowarn=12. Would it be possible to add a vlink -wfail option, like vasm? I was debugging stale binaries at one point because the build failed and didn't see the linker warnings in the middle of the output. The possible issue: Why is it that the numbers are only appended to the generated section names for chip or fast mem?. I deliberately broke my linker script [to see the autogenerated names] and this was the output: Warning 64: Section hunk_to_rawseg_loadfile(code) was not recognized by target linker script. I still want to: - Test that merging sections of same type but different name works as expected - Test with some 3rd party executables. |
Spotted a bug in the linker script. It needed a * after the "chip" as well in the chip section so it reads:
*(*chip*). Without this, it was not pulling in sections with generated names like "codechip0001" Code:
PHDRS { Warning 22: Attributes of section .chip were changed from r-x- to rwx- in hunk_to_rawseg_loadfile. |
Quote:
I even had the GNU-tools in mind, which may use section names like .datachip to detect memory attributes. I tried to follow this syntax as well. Quote:
Quote:
But your and hooverphonique's comments and irritations make me rethink that naming. Maybe I should change it. Quote:
|
All times are GMT +2. The time now is 14:52. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.