English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 07 December 2014, 00:04   #21
deadwood
Registered User

 
Join Date: Nov 2014
Location: Poland
Posts: 45
Thanks. I'll try it out and report back.
deadwood is offline  
AdSense AdSense  
Old 07 December 2014, 09:04   #22
deadwood
Registered User

 
Join Date: Nov 2014
Location: Poland
Posts: 45
@phx

.weak

It now uses the symbol, but also adds the offset, so the resulting position is wrong I think:

Code:
  88:	4879 0000 0000 	pea 0 <Workbench_3_Workbench_ExpungeLib>
			8a: R_68K_32	__LIBS_LIST__
  8e:	4eb9 0000 0000 	jsr 0 <Workbench_3_Workbench_ExpungeLib>
			90: R_68K_32	_set_open_libraries_list
  94:	508f           	addql #8,%sp
  96:	4a80           	tstl %d0
  98:	6700 008a      	beqw 124 <Workbench_InitLib+0xc4>
  9c:	2f0e           	movel %fp,%sp@-
  9e:	4878 0001      	pea 1 <Workbench_3_Workbench_ExpungeLib+0x1>
  a2:	4878 0001      	pea 1 <Workbench_3_Workbench_ExpungeLib+0x1>
  a6:	4879 0000 00b8 	pea b8 <Workbench_InitLib+0x58>
			a8: R_68K_32	__INIT_LIST__+0xb8
  ac:	4eb9 0000 0000 	jsr 0 <Workbench_3_Workbench_ExpungeLib>
			ae: R_68K_32	_set_call_funcs
Also with 7th Dec build, I'm getting new warnings:

warning 62: imported symbol <__aros_libreq_SysBase.0> was not referenced

warning 62: imported symbol <.> was not referenced

I'll test the remainder of your fixes today
deadwood is offline  
Old 07 December 2014, 09:45   #23
deadwood
Registered User

 
Join Date: Nov 2014
Location: Poland
Posts: 45
@phx

Could you also implement for two more directives?

.zero - this seems to be equal to .skip

Code:
/* This is how to allocate empty space in some section.  The .zero
   pseudo-op is used for this on most svr4 assemblers.  */

#define SKIP_ASM_OP	"\t.zero\t"
.swbeg[l]

Example:

Code:
	.swbeg	&6
Documentation:

Code:
/* swbeg and swbegl are magic constants used on sysV68.  The compiler
   generates them before a switch table.  They tell the debugger and
   disassembler that a switch table follows.  The parameter is the
   number of elements in the table.  swbeg means that the entries in
   the table are word (2 byte) sized, and swbegl means that the
   entries in the table are longword (4 byte) sized.  */
{"swbeg", 4,	one(0045374),	one(0177777), "#w",   m68000up | mcfisa_a },
{"swbegl", 6,	one(0045375),	one(0177777), "#l",   m68000up | mcfisa_a },
I checked the GAS-generated object disassembly and I don't see any magic values there, so I think .swbeg[l] can just be ignored.

Source:
Code:
	jmp %pc@(2,%d1:w)
	.balignw 2,0x284c
	.swbeg	&6
.L182:
	.word .L177-.L182
	.word .L178-.L182
	.word .L179-.L182
	.word .L180-.L182
	.word .L181-.L182
	.word .L181-.L182
.L181:
	move.w %d0,%a3
GAS:
Code:
    12ee:	4efb 1002      	jmp %pc@(12f2 <HandleWin+0x2fa>,%d1:w)
    12f2:	00bc           	.short 0x00bc
    12f4:	00e0           	.short 0x00e0
    12f6:	0104           	btst %d0,%d4
    12f8:	0128 000c      	btst %d0,%a0@(12)
    12fc:	000c           	.short 0x000c
    12fe:	3640           	moveaw %d0,%a3
deadwood is offline  
Old 07 December 2014, 11:00   #24
deadwood
Registered User

 
Join Date: Nov 2014
Location: Poland
Posts: 45
@phx

I think something is broken with latest nightly. I now get these warnings/errors:

Code:
/ssd/deadwood/repo-svnorg-trunk/toolchain-m68k/m68k-aros-ld: Warning: size of symbol `gad' changed from 24 in /ssd/deadwood/repo-svnorg-trunk/master-amiga-m68k-VASM-O1/bin/amiga-m68k/gen/workbench/utilities/More/more.o to 4 in /ssd/deadwood/repo-svnorg-trunk/master-amiga-m68k-VASM-O1/bin/amiga-m68k/gen/workbench/utilities/More/req.o
/ssd/deadwood/repo-svnorg-trunk/master-amiga-m68k-VASM-O1/bin/amiga-m68k/gen/workbench/utilities/More/req.o:(.bss+0x10): multiple definition of `fontheight'
/ssd/deadwood/repo-svnorg-trunk/master-amiga-m68k-VASM-O1/bin/amiga-m68k/gen/workbench/utilities/More/more.o:(.bss+0x314): first defined here
The toolchain is gcc->vasm->ld

It seems that variables which are marked in C code as static (visible only in compilation unit) now are visible across compilation units.

Here is how fontheight is in GCC generated assembler (same in more.s and req.s):

Code:
	.local	fontheight
	.comm	fontheight,2,2

Last edited by deadwood; 07 December 2014 at 11:21.
deadwood is offline  
Old 07 December 2014, 21:41   #25
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,019
Quote:
Originally Posted by deadwood View Post
.weak

It now uses the symbol, but also adds the offset, so the resulting position is wrong I think
*Sigh* ... that happens when you test with too simple examples which have a zero offset.

The fix is quite complex. Had to touch a dozend of files. Hope I didn't break anything else. Please try the new snapshot tomorrow.

Quote:
Could you also implement for two more directives?

.zero - this seems to be equal to .skip
Implemented.

Quote:
I checked the GAS-generated object disassembly and I don't see any magic values there, so I think .swbeg[l] can just be ignored.
Ok. Added and ignored.

Quote:
Originally Posted by deadwood View Post
It seems that variables which are marked in C code as static (visible only in compilation unit) now are visible across compilation units.

Here is how fontheight is in GCC generated assembler (same in more.s and req.s):

Code:
    .local    fontheight
    .comm    fontheight,2,2
This is allowed? Usually you would use .lcomm for that. And I don't think this is a new problem.

Ok. Also fixed. Next snapshot.
phx is offline  
Old 07 December 2014, 21:49   #26
deadwood
Registered User

 
Join Date: Nov 2014
Location: Poland
Posts: 45
Thanks, I'll let you know how it works
deadwood is offline  
Old 08 December 2014, 21:42   #27
deadwood
Registered User

 
Join Date: Nov 2014
Location: Poland
Posts: 45
Quote:
Originally Posted by phx View Post

This is allowed? Usually you would use .lcomm for that. And I don't think this is a new problem.

Ok. Also fixed. Next snapshot.
I tried 8th Dec snapshot and the problem is still there. What is however more disturbing is that I tried the original 1.7a version and now it also reports the same problem. :/

Here are current versions I use:
Code:
vasm 1.7b (c) in 2002-2014 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.0d (c) 2002-2014 Frank Wille
vasm std syntax module 3.8f (c) 2002-2014 Volker Barthelmann
vasm test output module 1.0 (c) 2002 Volker Barthelmann

Last edited by deadwood; 08 December 2014 at 21:47.
deadwood is offline  
Old 09 December 2014, 18:02   #28
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,019
Quote:
Originally Posted by deadwood View Post
I tried 8th Dec snapshot and the problem is still there.
Not here. When the other bugs are fixed, then you definitely have the new version. In this case you have to provide more details for reproduction. For example a small source and all options you pass to vasm. Do you work with ELF or a.out objects?

Quote:
What is however more disturbing is that I tried the original 1.7a version and now it also reports the same problem. :/
The .local/.comm problem was always there (because using .lcomm is recommended).
phx is offline  
Old 09 December 2014, 21:36   #29
deadwood
Registered User

 
Join Date: Nov 2014
Location: Poland
Posts: 45
Ok, I know what is going on. At some point I added "-ac" option which made the objects externally visible. Sorry for confusion. I'll proceed with testing other fixes.
deadwood is offline  
Old 10 December 2014, 11:24   #30
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,019
Quote:
Originally Posted by deadwood View Post
At some point I added "-ac" option which made the objects externally visible.
-ac means "allocate common symbols". A common symbol is externally visible by definition. The linker will then pick the common symbol with the largest size and allocate space in the bss section for it.

You declared the common symbol as .local, which turns it into a simple .bss-section allocation with local scope. The -ac option should no longer have an influence then. This is confusing and may be an additional problem...

Quote:
I'll proceed with testing other fixes.
Thanks.
phx is offline  
Old 10 December 2014, 20:20   #31
deadwood
Registered User

 
Join Date: Nov 2014
Location: Poland
Posts: 45
Seems the fixes and new directives work! Thanks a lot!
deadwood is offline  
Old 01 January 2015, 21:23   #32
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 1,736
@phx
Did you also check Vasm for the DIV*.L and MUL*.L bug which I found in PhxAss 4.45/46 ? I don't use Vasm, but Cosmos reported the same bug for Vasm 1.5b (the latest available binary Hasenbraten)
http://eab.abime.net/showpost.php?p=994297&postcount=51

Happy New Year !
PeterK is offline  
Old 02 January 2015, 00:25   #33
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,019
Yes, he already reported a problem with MUL*.L, which is not a real bug, like the DIV*.L issue (DIV*.L is ok in vasm). For MUL*.L Dn,Dl vasm sets Dh to zero (bit 0-2 of second word). Unlike with DIV, where there are conflicts with DIV*L.L, those bits are ignored with MUL.

Different assemblers set Dh either to the same value of Dl (Devpac, Barfly, PhxAss, ...) or set Dh to zero (GNU-as, vasm). Both will work.

But now I decided that Dh=Dl might be more logical and commited this change yesterday - i.e. the snapshot from this morning should include it.
phx is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
vasm question marduk_kurios Coders. Asm / Hardware 7 14 February 2014 21:06
Assembling Gravity Force 2 source code absence Coders. General 5 13 May 2012 12:44
[REQ:ASM] Assembling and running jman Coders. Tutorials 9 07 May 2011 19:39
Devpac and assembling for absolute addresses h0ffman Coders. General 10 21 March 2011 20:12
vasm 1.5 RFC phx Coders. General 30 11 December 2010 03:08

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 01:08.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.20364 seconds with 14 queries