[z88dk-dev] z80asm: build a consolidated object file

Bridge to the z88dk-developers mailing list
Post Reply
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

[z88dk-dev] z80asm: build a consolidated object file

Post by alvin »

Is it possible to build a consolidated object file from a list of object files?

Something like:

z80asm a.o b.o -o consolidated.o

I'm compiling to a binary from a list of source files but I need to stop at object files so that the linking to binary can be done twice. The first time is done with some fake constants defined, which is used in source, then the result is compressed. The second time the binary is made with correct constants that indicate compressed file sizes (these constants would be in a portion that is not compressed). I need to use the same object files so that the final binary size is repeatable -- c compilation twice in a row can generate different code.

I can make a bunch of object files by giving zcc the project.lst. I could also build a binary from those object files if I had a second project2.lst whose only difference is .o extension for each file. But I'd rather not have to maintain two different list files. In the absence of z80asm able to consolidate multiple .o files, I could also create a special case in zcc that will skip generation of individual .o files so that z80asm is given a list of asm files instead but I think this is something z80asm should be able to do.

Another option is to create a library out of the source files and use that to build the binaries. This is workable but the semantics are slightly different between .o and .lib : .lib entries are selectively extracted as needed by the binary but with .o everything goes into the binary. A person may want to build a binary with everything in it, including unreferenced code and data, and that demands a .o



------------------------------------------------------------------------------
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

I implemented the multiple asm files to a single object file method in zcc but this does not work either.

Two examples:

(1) Multiple .o files generated

zcc +zx -c file1.c file2.c file3.asm

One .o file is generated per input source file: file1.o, file2.o, file3.o

(2) Consolidated .o file generated from all input source files

zcc +zx -c file1.c file2.c file3.asm -o consolidated

The file "consolidated.o" should be generated from all the input source files. The difference from the previous example is that an output filename is supplied, which has no meaning for the multiple .o case.

(1) is working as it should. In (2) z80asm does nothing. No error message and no output file produced. zcc is taking all the source files to .asm and then getting z80asm is to make an object file out of them like this:

z80asm --output=consolidated.o (various -D, include paths) -s file1.asm file2.asm file3.asm

And it's this line that does nothing.



------------------------------------------------------------------------------
pscust
Well known member
Posts: 194
Joined: Thu Jun 23, 2011 3:34 pm

Post by pscust »

z80asm does not have the feature of building a consolidated object file.

Let me analyze the feature change impacts over the week-end.




On 9/21/16, alvin (alvin_albrecht@...) <lists@...> wrote:
I implemented the multiple asm files to a single object file method in zcc
but this does not work either.

Two examples:

(1) Multiple .o files generated

zcc +zx -c file1.c file2.c file3.asm

One .o file is generated per input source file: file1.o, file2.o, file3.o

(2) Consolidated .o file generated from all input source files

zcc +zx -c file1.c file2.c file3.asm -o consolidated

The file "consolidated.o" should be generated from all the input source
files. The difference from the previous example is that an output filename
is supplied, which has no meaning for the multiple .o case.

(1) is working as it should. In (2) z80asm does nothing. No error message
and no output file produced. zcc is taking all the source files to .asm and
then getting z80asm is to make an object file out of them like this:

z80asm --output=consolidated.o (various -D, include paths) -s file1.asm
file2.asm file3.asm

And it's this line that does nothing.



------------------------------------------------------------------------------
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

z80asm does not have the feature of building a consolidated object file.
Let me analyze the feature change impacts over the week-end.
Did you have a chance to have a look at that yet? I am going to revert zcc to trying to form a consolidated object out of .o files instead of .asm as it is now so that could be used for testing.

One other thing with map files :- z80asm is currently listing ASMHEAD, ASMTAIL and ASMSIZE for all sections including empty ones. Is it possible to prune out the empty sections to reduce some of the clutter?

As an example, this is part of a map file from a recent compile:


ASMHEAD_code_alloc_obstack = $0165 ; G
ASMHEAD_code_arch = $0165 ; G
ASMHEAD_code_bifrost2 = $0165 ; G
ASMHEAD_code_bifrost_h = $0165 ; G
ASMHEAD_code_bifrost_l = $0165 ; G
ASMHEAD_code_compress_aplib = $0165 ; G
ASMHEAD_code_compress_zx7 = $0165 ; G
ASMTAIL_code_alloc_malloc = $0165 ; G
ASMTAIL_code_alloc_obstack = $0165 ; G
ASMTAIL_code_arch = $0165 ; G
ASMTAIL_code_bifrost2 = $0165 ; G
ASMTAIL_code_bifrost_h = $0165 ; G
ASMTAIL_code_bifrost_l = $0165 ; G
ASMTAIL_code_compress_aplib = $0165 ; G
asm_dzx7_standard = $0165 ; G asm_dzx7_standard
dzx7s_copy_byte_loop = $0167 ; L asm_dzx7_standard
dzx7s_main_loop = $0169 ; L asm_dzx7_standard
dzx7s_len_size_loop = $0173 ; L asm_dzx7_standard
dzx7s_len_value_loop = $0179 ; L asm_dzx7_standard
dzx7s_rld_next_bit = $0190 ; L asm_dzx7_standard
dzx7s_offset_end = $019A ; L asm_dzx7_standard
dzx7s_exit = $01A3 ; L asm_dzx7_standard
dzx7s_next_bit = $01A6 ; L asm_dzx7_standard
ASMHEAD_code_ctype = $01AC ; G
ASMTAIL_code_compress_zx7 = $01AC ; G


If the empty sections are removed it would look like this:


ASMHEAD_code_compress_zx7 = $0165 ; G
asm_dzx7_standard = $0165 ; G asm_dzx7_standard
dzx7s_copy_byte_loop = $0167 ; L asm_dzx7_standard
dzx7s_main_loop = $0169 ; L asm_dzx7_standard
dzx7s_len_size_loop = $0173 ; L asm_dzx7_standard
dzx7s_len_value_loop = $0179 ; L asm_dzx7_standard
dzx7s_rld_next_bit = $0190 ; L asm_dzx7_standard
dzx7s_offset_end = $019A ; L asm_dzx7_standard
dzx7s_exit = $01A3 ; L asm_dzx7_standard
dzx7s_next_bit = $01A6 ; L asm_dzx7_standard
ASMHEAD_code_ctype = $01AC ; G
ASMTAIL_code_compress_zx7 = $01AC ; G


which is far more readable.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
pscust
Well known member
Posts: 194
Joined: Thu Jun 23, 2011 3:34 pm

Post by pscust »

z80asm does not have the feature of building a consolidated object file.
Let me analyze the feature change impacts over the week-end.
Yes, I had a go at it, but ended up duplicating most of the link module and
still not having a working solution and reverting back to square 1. The
problem is the extensive use of global variables to keep state in the whole
of z80asm that make changes difficult.

I will have a second go.

Just to make clear what we are trying to accomplish:
- when z80asm is called with -o objfile and without -b, a consolidated
objfile.o shall be created
- the object file shall contains all the modules included in the command
line plus any required modules linked from libraries
- all address labels shall be computed for an image at address zero - ready
for the second link run
- all DEFC expressions shall not be computed - will be on the second link
run


One other thing with map files :- z80asm is currently listing ASMHEAD,
ASMTAIL
and ASMSIZE for all sections including empty ones. Is it possible to
prune out
the empty sections to reduce some of the clutter?
Yes, it can be done easily.
While we are at it, I think that z80asm should not pollute the namespace
with "normal" labels. I suggest to rename these __z80asm_head,
__z80asm_tail, ... What do you think?




On Tue, Oct 4, 2016 at 1:33 AM, alvin (alvin_albrecht@...) <
lists@...> wrote:
z80asm does not have the feature of building a consolidated object file.
Let me analyze the feature change impacts over the week-end.
Did you have a chance to have a look at that yet? I am going to revert
zcc to trying to form a consolidated object out of .o files instead of .asm
as it is now so that could be used for testing.

One other thing with map files :- z80asm is currently listing ASMHEAD,
ASMTAIL and ASMSIZE for all sections including empty ones. Is it possible
to prune out the empty sections to reduce some of the clutter?

As an example, this is part of a map file from a recent compile:


ASMHEAD_code_alloc_obstack = $0165 ; G
ASMHEAD_code_arch = $0165 ; G
ASMHEAD_code_bifrost2 = $0165 ; G
ASMHEAD_code_bifrost_h = $0165 ; G
ASMHEAD_code_bifrost_l = $0165 ; G
ASMHEAD_code_compress_aplib = $0165 ; G
ASMHEAD_code_compress_zx7 = $0165 ; G
ASMTAIL_code_alloc_malloc = $0165 ; G
ASMTAIL_code_alloc_obstack = $0165 ; G
ASMTAIL_code_arch = $0165 ; G
ASMTAIL_code_bifrost2 = $0165 ; G
ASMTAIL_code_bifrost_h = $0165 ; G
ASMTAIL_code_bifrost_l = $0165 ; G
ASMTAIL_code_compress_aplib = $0165 ; G
asm_dzx7_standard = $0165 ; G asm_dzx7_standard
dzx7s_copy_byte_loop = $0167 ; L asm_dzx7_standard
dzx7s_main_loop = $0169 ; L asm_dzx7_standard
dzx7s_len_size_loop = $0173 ; L asm_dzx7_standard
dzx7s_len_value_loop = $0179 ; L asm_dzx7_standard
dzx7s_rld_next_bit = $0190 ; L asm_dzx7_standard
dzx7s_offset_end = $019A ; L asm_dzx7_standard
dzx7s_exit = $01A3 ; L asm_dzx7_standard
dzx7s_next_bit = $01A6 ; L asm_dzx7_standard
ASMHEAD_code_ctype = $01AC ; G
ASMTAIL_code_compress_zx7 = $01AC ; G


If the empty sections are removed it would look like this:


ASMHEAD_code_compress_zx7 = $0165 ; G
asm_dzx7_standard = $0165 ; G asm_dzx7_standard
dzx7s_copy_byte_loop = $0167 ; L asm_dzx7_standard
dzx7s_main_loop = $0169 ; L asm_dzx7_standard
dzx7s_len_size_loop = $0173 ; L asm_dzx7_standard
dzx7s_len_value_loop = $0179 ; L asm_dzx7_standard
dzx7s_rld_next_bit = $0190 ; L asm_dzx7_standard
dzx7s_offset_end = $019A ; L asm_dzx7_standard
dzx7s_exit = $01A3 ; L asm_dzx7_standard
dzx7s_next_bit = $01A6 ; L asm_dzx7_standard
ASMHEAD_code_ctype = $01AC ; G
ASMTAIL_code_compress_zx7 = $01AC ; G


which is far more readable.



------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

>Yes, I had a go at it, but ended up duplicating most of the link module and still not having a working solution and reverting back to square 1. The >problem is the extensive use of global variables to keep state in the whole of z80asm that make changes difficult.

>Just to make clear what we are trying to accomplish:
>- when z80asm is called with -o objfile and without -b, a consolidated objfile.o shall be created
>- the object file shall contains all the modules included in the command line plus any required modules linked from libraries
>- all address labels shall be computed for an image at address zero - ready for the second link run
>- all DEFC expressions shall not be computed - will be on the second link run

Yes except the second one:

>- the object file shall contains all the modules included in the command line plus any required modules linked from libraries

I think this is different when creating a single file object:

z80asm test.asm

It looks like no linking is done against library files even if I add them to the command line. To be consistent it should be the same for a consolidate object.

>> One other thing with map files :- z80asm is currently listing ASMHEAD, ASMTAIL
>> and ASMSIZE for all sections including empty ones. Is it possible to prune out
>> the empty sections to reduce some of the clutter?
>
>Yes, it can be done easily.
>While we are at it, I think that z80asm should not pollute the namespace with "normal" labels. I suggest to rename these __z80asm_head, >__z80asm_tail, ... What do you think?

Or maybe __section_head_* ?

Other z80 linkers are making a summary of sections separate from map symbols but I think it may be better to inline them in the symbol list as is done now. Maybe some extra blank lines can make the sections more easily located?

I think we're looking up some ASMHEAD* type symbols in appmake so we'll have to make some changes there too.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
pscust
Well known member
Posts: 194
Joined: Thu Jun 23, 2011 3:34 pm

Post by pscust »

I've committed z80asm with the possibility of building a consolidated
object file.

Add consolidated object file.
When -o objectfile is given without -b, all the object modules from the
command line
are merged into one consolidated object file. The module local symbols
are renamed
<module>_<symbol> to avoid clashes in the merged symbol table.

Please let me know of any issues.


On Thu, Oct 6, 2016 at 3:45 AM, alvin (alvin_albrecht@...) <
lists@...> wrote:
>Yes, I had a go at it, but ended up duplicating most of the link module
and still not having a working solution and reverting back to square 1. The
problem is the extensive use of global variables to keep state in the
whole of z80asm that make changes difficult.

>Just to make clear what we are trying to accomplish:
>- when z80asm is called with -o objfile and without -b, a consolidated
objfile.o shall be created
>- the object file shall contains all the modules included in the command
line plus any required modules linked from libraries
>- all address labels shall be computed for an image at address zero -
ready for the second link run
>- all DEFC expressions shall not be computed - will be on the second
link run

Yes except the second one:

>- the object file shall contains all the modules included in the command
line plus any required modules linked from libraries

I think this is different when creating a single file object:

z80asm test.asm

It looks like no linking is done against library files even if I add them
to the command line. To be consistent it should be the same for a
consolidate object.

>> One other thing with map files :- z80asm is currently listing
ASMHEAD, ASMTAIL
>> and ASMSIZE for all sections including empty ones. Is it possible to
prune out
>> the empty sections to reduce some of the clutter?
>
>Yes, it can be done easily.
>While we are at it, I think that z80asm should not pollute the namespace
with "normal" labels. I suggest to rename these __z80asm_head,
__z80asm_tail, ... What do you think?
Or maybe __section_head_* ?

Other z80 linkers are making a summary of sections separate from map
symbols but I think it may be better to inline them in the symbol list as
is done now. Maybe some extra blank lines can make the sections more
easily located?

I think we're looking up some ASMHEAD* type symbols in appmake so we'll
have to make some changes there too.



------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

I've committed z80asm with the possibility of building a consolidated object file.

Add consolidated object file.
When -o objectfile is given without -b, all the object modules from the command line
are merged into one consolidated object file. The module local symbols are renamed
<module>_<symbol> to avoid clashes in the merged symbol table.

Please let me know of any issues.
It's almost working. I have an issue with a function in a separate source file that has no references from the rest of the source files that isn't appearing in the output object file. It's like z80asm is behaving as if it is linking, pruning this function out as it has no references.

z80asm --output=out.o @objects.lst ;; object.lst contains a.o, b.o, c.o, d.o

d.o contains sole public label "foo" but foo is absent from the object file. foo is not referenced by anything in a.o, b.o, c.o.

z80nm shows that foo is missing and changing d.o to precede c.o does not change the fact that d.o is missing from the object file.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

One other thing with map files :- z80asm is currently listing ASMHEAD, ASMTAIL and ASMSIZE for all sections including empty ones. Is it possible to prune out the empty sections to reduce some of the clutter?
This is probably a case of careful what you wish for :P

With the current changes, the symbols for empty sections are not generated. The new c library depends on those symbols still being defined.

To demarcate the BSS section this is in the memory map:


section BSS_UNINITIALIZED

section bss_driver
section bss_font
section bss_clib
include "../../clib_bss.inc"
section bss_lib
section bss_compiler
section bss_user

SECTION BSS_END


"section BSS_UNINITIALIZED" might be empty and "SECTION BSS_END" will be empty. These two dummy sections must be used to bracket all the bss sections because it's not known what the last bss section's name will be (all bss sections have to be explicitly named currently) without using the dummy section name.

To initialize the bss section, this code is being run:

; initialize bss section

IF (__crt_model | __crt_initialize_bss)

EXTERN asm_memset
EXTERN __BSS_UNINITIALIZED_tail, __BSS_END_tail

ld hl,__BSS_UNINITIALIZED_tail
ld bc,__BSS_END_tail - __BSS_UNINITIALIZED_tail

ld e,0
call asm_memset

ENDIF

But since "SECTION BSS_END" is empty, "__BSS_END_tail" is undefined.


So we still need those symbols defined. The empty sections are cluttering up the output map file and makes that harder to identify where sections begin and end. That's the problem trying to be solved but I can see we can't just get rid of these empty section symbols. Maybe emit the empty section symbols (with a section summary?) at the end of the map file separately or only omit them from the map file to make it more readable. The latter is probably not good either since someone may want to look up those values too.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
pscust
Well known member
Posts: 194
Joined: Thu Jun 23, 2011 3:34 pm

Post by pscust »

I'll revert the change to prune empty sections. It's just an if statement.

In respect to map file cluttering, I can sort the symbols by name instead
of by address. This way all the __* will appear together.

Regards

Em 09/10/2016 21:37, "alvin (alvin_albrecht@...)" <
lists@...> escreveu:
One other thing with map files :- z80asm is currently listing ASMHEAD,
ASMTAIL and ASMSIZE for all sections including empty ones. Is it possible
to prune out the empty sections to reduce some of the clutter?
This is probably a case of careful what you wish for :P

With the current changes, the symbols for empty sections are not
generated. The new c library depends on those symbols still being defined.

To demarcate the BSS section this is in the memory map:


section BSS_UNINITIALIZED

section bss_driver
section bss_font
section bss_clib
include "../../clib_bss.inc"
section bss_lib
section bss_compiler
section bss_user

SECTION BSS_END


"section BSS_UNINITIALIZED" might be empty and "SECTION BSS_END" will be
empty. These two dummy sections must be used to bracket all the bss
sections because it's not known what the last bss section's name will be
(all bss sections have to be explicitly named currently) without using the
dummy section name.

To initialize the bss section, this code is being run:

; initialize bss section

IF (__crt_model | __crt_initialize_bss)

EXTERN asm_memset
EXTERN __BSS_UNINITIALIZED_tail, __BSS_END_tail

ld hl,__BSS_UNINITIALIZED_tail
ld bc,__BSS_END_tail - __BSS_UNINITIALIZED_tail

ld e,0
call asm_memset

ENDIF

But since "SECTION BSS_END" is empty, "__BSS_END_tail" is undefined.


So we still need those symbols defined. The empty sections are cluttering
up the output map file and makes that harder to identify where sections
begin and end. That's the problem trying to be solved but I can see we
can't just get rid of these empty section symbols. Maybe emit the empty
section symbols (with a section summary?) at the end of the map file
separately or only omit them from the map file to make it more readable.
The latter is probably not good either since someone may want to look up
those values too.



------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

There is still a problem with the consolidated object file.

The consolidated object file is created, here is the example command line I am using:

zcc +zx -vn -c -SO3 -clib=sdcc_iy --max-allocs-per-node200000 --opt-code-size --fsigned-char @zx7_zproject.lst -o pietro_bros

If I do a z80nm on pietro_bros.o output by the above:
File pietro_bros.o at $0000: Z80RMF08
Name: pietro_bros
Names:
G A $0000 _btiles (section rodata_user)
G A $0000 _pietro_font (section FONT)
G A $033F _hall_valids (section data_compiler)
G A $033D _initals (section data_compiler)
G A $0327 _hall_names (section data_compiler)
......
G A $4446 _spr_tile_dir (section code_compiler)
G A $018A _zx_print_str (section code_user)
G A $01C0 _zx_print_int (section code_user)
G A $01DC _zx_print_chr (section code_user)
G A $01F5 _zx_print_bonus_time (section code_user)
G A $0000 pietro_loader (section LOADER)
G A $0057 l_ret (section LOADER)
Everything publicly exported is in there including the unreferenced code "pietro_loader" so that problem was solved. However you'll notice there are no EXTERN references.

If I try to compile using that object file:

zcc +zx -zorg=%PADDR% -startup=31 -SO3 -clib=sdcc_iy --max-allocs-per-node200000 --opt-code-size --fsigned-char zx7_pietro_sizes.asm pietro_bros.o -o pietro_bros -pragma-include:zpragma.inc

I get a whole bunch of symbol not defined errors:
Error at file 'C:\Users\alvin\AppData\Local\Temp\zcc84FF4.asm' line 1411: symbol '___str_15' not defined
Error at file 'C:\Users\alvin\AppData\Local\Temp\zcc84FF4.asm' line 1409: symbol '___str_14' not defined
Error at file 'C:\Users\alvin\AppData\Local\Temp\zcc84FF4.asm' line 1407: symbol '___str_13' not defined
...
file 'C:\Users\alvin\AppData\Local\Temp\zcc84FF6.asm' line 2891: symbol 'l_enemy_walk_00137' not defined
Error at file 'C:\Users\alvin\AppData\Local\Temp\zcc84FF6.asm' line 2889: symbol 'l_enemy_walk_00137' not defined
Error at file 'C:\Users\alvin\AppData\Local\Temp\zcc84FF6.asm' line 2886: symbol 'l_enemy_walk_00218' not defined
...
file 'C:\Users\alvin\AppData\Local\Temp\zcc84FF5.asm' line 751: symbol '_srand_fastcall' not defined
Error at file 'C:\Users\alvin\AppData\Local\Temp\zcc84FF5.asm' line 742: symbol '_in_test_key' not defined
Error at file 'C:\Users\alvin\AppData\Local\Temp\zcc84FF5.asm' line 739: symbol '_in_wait_nokey' not defined
Error at file 'C:\Users\alvin\AppData\Local\Temp\zcc84FF5.asm' line 738: symbol '_zx_border_fastcall' not defined
The first two blocks of errors above are local symbols.

The ___str_* symbols are local and defined like this in the asm source:

1321 0384 SECTION code_compiler
1325 0384 _game_draw_back:
1326 0384 CD 00 00 call ___sdcc_enter_ix
1327 0387 F5 push af
1328 0388 21 00 00 ld hl,_s_lin1
....
1448 0480 SECTION rodata_compiler
1449 0000 ___str_0:
1450 0000 3C DEFM "<"
1451 0001 00 DEFB 0x00

Code inside section "code_compiler" is referencing the local symbol "___str_0" defined in a different section.

The "l_*" type symbols are local labels inside the same function and same section:

2892 0D77 l_enemy_walk_00218:
2893 0D77 FA 63 0E jp M,l_enemy_walk_00137
2894 0D7A CD 00 00 call _spr_move_horizontal
2895 0D7D C3 63 0E jp l_enemy_walk_00137
...
3036 0E63 l_enemy_walk_00137:
3037 0E63 C9 ret

The third block of undefined symbols are library functions. I'm expecting the linker to pull them in from the library but I'm wondering if the missing EXTERN types in z80nm's index of pietro_bros.o prevents that.


Functionally I am expecting the consolidated object file to behave very similarly to linking against a library except I expect the entire object file to be made part of the output binary instead of only referenced modules as with a library.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

I have found the problem, and hopefully fixed it.

The list of imported symbols from all object files being consolidated also needs to be merged, keeping in the external list library symbols, but removing from the list symbols that are undefined in one module but defined in another.
Getting closer. z80nm now shows the extern library symbols but the local symbols are still not resolved within the .o
I was not able to run your setup to try to compile pietro_bros.
If I extract the nightly build to a directory, what are the environment variables that I need to tweak to have zcc + sdcc run?
Just ZCCCFG and the path.

http://www.z88dk.org/wiki/doku.php?id=t ... nt#windows

You should probably put the new z88dk/bin at the front of the path to make sure it's not picking up binaries from your other install.

There's a newer sdcc binary in http://z88dk.cvs.sourceforge.net/viewvc ... _patch.zip which you can put in z88dk/bin but it shouldn't affect whether things compile.

zcompile_zx7.bat is the batch file that builds the compressed binary and uses the consolidated object. You may want to put "exit /B" on line 50 to stop the build right after the object file is made. Then you can enter the next line manually to catch all the errors.

zcompile_sdcc.bat is the regular build that will work.

There are compile lines in there for sccz80 but the program is now too big to use sccz80.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

Fixed. This one was tough, as my test code did not exercise the bug, which happened with local symbols containing '_'.
I managed to run zcompile_zx7.bat and to play the resulting Mario clone.
I have one more related bug for you :) It's happening in the updated source so download the source package again.

For some reason, in pietro_loader.asm, the symbols "__LOADER_head" and "__LOADER_CODE_tail" are being made public when a consolidated object is built. It is only those two symbols despite other section symbols being used in the same file.
SECTION MCLOAD

PUBLIC mini_loader

EXTERN __LOADER_head, __LOADER_CODE_tail

...
These symbols are *not* made public when the same file is assembled into a solitary object file.


You can try it like this:

z80asm pietro_loader.asm
z80nm pietro_loader.o

Here "__LOADER_head" and "__LOADER_CODE_tail" are shown as extern.

Now try this:

z80asm --output=pietro_loader.o pietro_loader.asm pietro_zx.asm
z80nm pietro_loader.o

Here "__LOADER_head" and "__LOADER_CODE_tail" are shown as global.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

This one is also fixed now. Thanks for reporting.
All is working now.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Post Reply