VASM locally scoped labels in HUNK_SYMBOL

[hop]

I have noticed that VASM MOT/Amiga doesn't seem to add locally-scoped symbols (those starting with a dot) to HUNK_SYMBOL.

For example in this test program

	SECTION S_0,CODE
Start:
	moveq 	#0,d0
	moveq	#4-1,d7
.loop:	add.w	#1,d0
	dbf	d7,.loop
	moveq	#4-1,d7

	bsr	Sub1
	bsr	Sub2

	rts
;------------------------------------------------
Sub1:
	moveq	#4-1,d7
	moveq 	#0,d1
	moveq	#4-1,d7
.loop:	add.w	#1,d1
	dbf	d7,.loop
	moveq	#4-1,d7
	rts
;------------------------------------------------
Sub2:
	moveq	#4-1,d7
	moveq 	#0,d1
	moveq	#4-1,d7
.loop:	add.w	#1,d1
	dbf	d7,.loop
	moveq	#4-1,d7
	rts
	END

Assembled with

vasmm68k_mot -Fhunkexe -kick1hunks -no-opt -pic -wfail -warncomm -o LocalLabelTest LocalLabelTest.s

The hunk symbol contains only the global labels:

    Module 0 : CODE ,PUBLIC   ,60 Bytes.
      hunk_symbol:
        Start = 00000000
        Sub1 = 00000018
        Sub2 = 0000002a

Is there a reason for this, or any options to control it?

[Thomas Richter]

Originally Posted by hop

I have noticed that VASM MOT/Amiga doesn't seem to add locally-scoped symbols (those starting with a dot) to HUNK_SYMBOL.
Is there a reason for this, or any options to control it?

The reason that locally scoped symbols are not added to HUNK_SYMBOL is that they are locally scoped. HUNK_SYMBOL does not know anything about scopes, and this could cause conflicts when linking because it means that some symbols are doubly defined with different values.

[hop]

Originally Posted by Thomas Richter

The reason that locally scoped symbols are not added to HUNK_SYMBOL is that they are locally scoped. HUNK_SYMBOL does not know anything about scopes, and this could cause conflicts when linking because it means that some symbols are doubly defined with different values.

Thanks. That makes sense.

[a/b]

You could say that's by definition, as their name implies (local). Similarly how the static variables in C are local to their file and aren't exported as globals. As for a reason, they could potentially be optimized out, unlike globals that have to be accessible from other modules during linking.
So you have a direct control over their scope by using a global name instead. That's how it was meant to work (not sure about extra options to change it).

[Wepl]

I find this also annoying and use BAsm if I want debug something. It includes also all dot labels in the HUNK_SYMBOL.

[hop]

Originally Posted by Wepl

I find this also annoying and use BAsm if I want debug something. It includes also all dot labels in the HUNK_SYMBOL.

Thanks for making me aware of this. It would be great if VASM had an option to include local labels in HUNK_SYMBOL, which could error if optimisations are enabled, for reasons stated above.

I think we also have to be careful to distinguish between global symbols and exported symbols. I imagine exported symbols can never be optimised out, but global symbols could.

[Don_Adan]

In general, I never like/use local labels.
Hardest to find in big source code for me.
For ".loop" I used "loop1", "loop2", "loop3" etc or "loopxx" like "loopSUB1".
But Im strange.

[phx]

Originally Posted by Thomas Richter

HUNK_SYMBOL does not know anything about scopes, and this could cause conflicts when linking because it means that some symbols are doubly defined with different values.

Yes and no.
The linker uses symbols from

HUNK_EXT

only, for resolving references.

HUNK_SYMBOL

is for debuggers, which could theoretically also contain double symbol definitions at different offsets, if the debugger can deal with it.

Originally Posted by hop

It would be great if VASM had an option to include local labels in HUNK_SYMBOL

Could be easily done. But it really should be an option, because I'm not 100% sure if double symbol definitions can cause problems with some debugging tools.

which could error if optimisations are enabled, for reasons stated above.

I don't know of any assembler optimisation which removes symbols.

[hop]

Originally Posted by phx

Could be easily done. But it really should be an option, because I'm not 100% sure if double symbol definitions can cause problems with some debugging tools.

That would be really helpful thanks. And agreed - it must be an option that defaults to off.

Originally Posted by phx

I don't know of any assembler optimisation which removes symbols.

Maybe I'm getting mixed up with C compiler optimisations sorry. I'm not very familiar with assembler optimisations, and I have probably incorrectly assumed that loop unrolling and code-elimination could remove code containing both local and global labels.

For example:

Start:
	moveq 	#0,d0
	moveq	#1,d7
.loop:	
	add.w	#1,d0
	dbf	d7,.loop
	rts

might unroll to

Start:
	moveq 	#0,d0
	add.w	#1,d0
	add.w	#1,d0
	moveq	#-1,d7
	rts

or if modified CCR values are not used

Start:
	add.w 	#2,d0
	moveq	#-1,d7
	rts

or pehaps even

Start:
	moveq 	#2,d0
	rts

With dead-stripping:

Start:
	moveq 	#0,d0
	bra	.end
	moveq	#1,d7
.loop:	
	add.w	#1,d0
	dbf	d7,.loop
.end
	rts

might assemble to this, removing the local

.loop

and

.end

labels

Start:
	moveq 	#0,d0
	rts

Perhaps global labels could also be optimised out:

Start:
	bsr	Red
	bsr	Red2
	rts

Red:
	moveq	#$7f,d7
.loop
	move.w	#$f00,$dff180
	dbf	d7,.loop
	rts

Red2:
	moveq	#$7f,d7
.loop
	move.w	#$f00,$dff180
	dbf	d7,.loop
	rts

could strip global label

Red2

, if the equivalent of common subexpression/code elimination is applied:

Start:
	bsr	Red
	bsr	Red
	rts

Red:
	moveq	#$7f,d7
.loop
	move.w	#$f00,$dff180
	dbf	d7,.loop
	rts

If the original code exported

Red

and

Red2

, then this (size) optimisation would not be possible.

I'm probably completely wrong here and there are very good reasons that optimising assemblers don't do this!

[paraj]

Most of those optimizations would only be legal with full program analysis and knowledge about the execution environment, and even then there are probably some issues. E.g. your first example of setting d7.l = -1 is not correct as dbf only modifies the lower word.

Regarding the local label thing, sounds like a good addition. If dots are generally allowed in labels by debuggers an option could be to export local symbols as

global.local

(like you can refer to them). That would avoid the duplication issue.

[Wepl]

I don't understand this discussion about duplicates and so on.
HUNK_SYMBOL contains that this offset has this name. A failsafe program which uses this info has anyway to check what has been provided by an alien binary. Are there printable chars at least, for example.
ReSource and BDebug have no problems with duplicates.

[phx]

Originally Posted by paraj

If dots are generally allowed in labels by debuggers an option could be to export local symbols as

global.local

(like you can refer to them). That would avoid the duplication issue.

Good idea, but perhaps symbols with a dot are still too common to avoid accidental conflicts? Maybe we should use a different character, which hopefully is still displayed by debugging tools. For a start I have chosen

$

. Also because

global..local

looks stupid.

Now the hunk-output module has two new options:

-dbg-local

adds local labels with their original name (like

1$

or

.abc

) to

HUNK_SYMBOL

.

-dbg-globloc

adds local labels by trying to construct a name out of their preceding global label and the original local label name:

global$local

(Examples:

main$1$

,

main$.abc

).
Code is committed for tomorrow's daily 2.0beta source snapshot. But I'm still open to new suggestions.

Originally Posted by Wepl

HUNK_SYMBOL contains that this offset has this name. A failsafe program which uses this info has anyway to check what has been provided by an alien binary. Are there printable chars at least, for example.

Yes, duplicate symbol names should be no problem here. But you never know.

ReSource and BDebug have no problems with duplicates.

Which is good enough, I guess (using BDebug myself).

[hop]

Originally Posted by phx

Now the hunk-output module has two new options:

-dbg-local

adds local labels with their original name (like

1$

or

.abc

) to

HUNK_SYMBOL

.

-dbg-globloc

adds local labels by trying to construct a name out of their preceding global label and the original local label name:

global$local

(Examples:

main$1$

,

main$.abc

).

Thanks very much! The changes are as expected in my test case. With

-dbg-local

the code from the original post now gives:

    Module 0 : CODE ,PUBLIC   ,60 Bytes.
      hunk_symbol:
        Start = 00000000
        .loop = 00000004
        Sub1 = 00000018
        Sub2 = 0000002a
        .loop = 0000001e
        .loop = 00000030

And with

-dbg-globloc

:

    Module 0 : CODE ,PUBLIC   ,60 Bytes.
      hunk_symbol:
        Start = 00000000
        Start$.loop = 00000004
        Sub1 = 00000018
        Sub2 = 0000002a
        Sub1$.loop = 0000001e
        Sub2$.loop = 00000030