From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-09-04 16:18:22
Hi!
On Thu, Sep 04, 2003 at 05:33:03AM -0700, David Holz wrote:
> This option would be at the assembler level so it would be optionally
> enabled per-file and wouldn't do anything to the labels used in c64.o and
> other existing sources. Besides, I don't use global labels like that, and
> neither should anybody else. All of my labels that use common names are
> inside .proc/.endproc nestings, hence the requested option wouldn't export
> them.
I think this is really too special. For one, making labels globally visible is
not the right way just to have them available in some label file. Second, the
next guy may also want to export local labels, or cheap locals or whatever,
and we end in having several different options just to auto-export some subset
of all non exported labels.
> Also, my programming style is usually to have lots of smaller files so I
> need to throw in a lot of exports manually to get it to link. Having
> auto-export of non-scoped labels would save me a lot of work in linking
> together my routines, either via command-line option, or .AUTOEXPORT control
> command. I'm on a single large file right now that somebody else wrote, but
> I normally take the multi-file approach with my own stuff.
I'm not sure if this will help you, but I'm sometimes using a C like approach
using the .global directive together with assembler include files. This works
similar as C header files.
---------------- header.inc ------------------
.global foo
.global bar
---------------- file1.asm ------------------
.include "header.inc"
foo: ; will get exported
jsr bar ; will get imported
---------------- file2.asm ------------------
.include "header.inc"
bar: ; will get exported
jsr foo ; will get imported
----------------------------------------------
> I tried various settings, and 2.9.1 doesn't seem to put anything more in the
> VICE listing with -g enabled than without.
You need to use -g for *all* the tools. If the assembler doesn't put the debug
infos into the object file, it doesn't help to instruct the linker to place it
into the vice label file.
> I might have done something
> wrong, but if the options are going to change, there's no point in trying to
> get the old way working.
Only the vice label file will go (together with the -Ln option). Debug info
generation will still work with the same switches as before, only the output
will get consolidated and there will be just one output file containing debug
information.
> I also did some of my own source tweaks (nothing
> to do with the labels), which is why I'm not at 2.9.2 yet.
Debug info works with several major versions now, so it is no new feature.
> Hey, as long as the new options throw as much info as possible at VICE, I'm
> happy. :)
One problem is that vice is not able to actually use all the info ld65 is/will
be able to generate. For example, the head branch is able to distinguish
between PC relative labels (defined with label:) and equates (defined with
'='), which would allow vice to act much smarter. Having symbols with
different addresses but the same name (as it is common if one has a lots of
assembler files) is also something vice is not able to handle. My version of
vice ignores zero page symbols when disassembling lda (zp),y and similar
opcodes. Symbol scopes will come soon, and this too does not help with vice.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-09-04 16:18:40 CEST