It is currently Mon Jul 24, 2017 1:46 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Mon Dec 05, 2016 1:12 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9793
Location: Rio de Janeiro - Brazil
When assembling projects with ca65, I often have ld65 output a "VICE label file" containing all labels I've used in my program and their addresses, so I can use this information for debugging (mostly for setting up breakpoints).

Unfortunately, ld65 doesn't output scope names to the label file, so there's no distinction between Video::Initialize and Audio::Initialize, for example. Both show up as just "Initialize", which is not helpful at all for debugging.

A while ago I started making heavy use of scopes to encapsulate things in my source code, but issues like this sometimes make me rethink this decision, and consider reverting to my old solution, which was to create artificial hierarchy using underscores (e.g. Video_Initialize and Audio_Initialize).

What are your thoughts on this? How do you conciliate scopes and debugging?


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 1:55 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5418
Location: Canada
That's a bit unfortunate. I find ca65's debug label output to be lacking in multiple ways (in particular I want to know what segment each label belongs to).

I don't have a solution for your problem, but here are some other reasons I don't particularly like cas65's scopes:
  • You can't use the same scope in more than one place, unlike C++ namespaces. (Exception: you can add constants from outside, e.g. "scope::newthing = 5")
  • Missing an .endscope or .endproc can have difficult to understand errors, especially affecting preprocessor directives (e.g. the resulting error is commonly "constant expression expected" at some distant place in the code where a global constant has been hidden by the local scope).
  • Related to previous point, if a symbol is not found in the local scope, it does not automatically check the global scope in some cases.
  • In assembly I often want to share code between related procedures. Trying to put them all in .proc scopes makes this annoying or ugly.
  • The required .endproc adds an additional line to every single procedure.

So at this point, I'm not a big fan of them. I think I find them useful mostly for cases where I'm including or cut/pasting some stuff together in the same file. As a surrogate for scopes, I do things like:
  • Anonymous labels : and local labels @ are more than sufficient for procedure type "scoping", for the most part.
  • Using multiple source files that are assembled separately makes an effective scope for symbols (i.e. only shared headers and import crosses between files).

One thing in favour of .proc scopes, though, the assembly definition I have for Notepad++ apparently lets you collapse/hide procedures that are marked with .proc/.endproc, which is really nice.


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 2:34 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2865
Location: Tampere, Finland
If you want to keep your old workflow and don't mind getting your hands dirty with some C/C++ coding, you could write your own tool to parse the cc65 debug files to generate a label file in whatever format you please.

You can use the library at https://github.com/cc65/cc65/tree/master/src/dbginfo to achieve this. https://github.com/cc65/cc65/blob/maste ... /dbginfo.h contains the interface, it's actually quite easy to use.

There's also an example that allows you to browse the contents of a debug file: https://github.com/cc65/cc65/blob/maste ... fo/dbgsh.c

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 2:38 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18662
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
Unfortunately, ld65 doesn't output scope names to the label file, so there's no distinction between Video::Initialize and Audio::Initialize, for example. Both show up as just "Initialize", which is not helpful at all for debugging.

I'd recommend reporting this deficiency in ld65's VICE export to the project's issue tracker. Call it something like "Improve mangling of scoped labels in VICE label file". If you don't have a GitHub account, I can report it for you if you wish.


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 6:45 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9793
Location: Rio de Janeiro - Brazil
rainwarrior wrote:
You can't use the same scope in more than one place, unlike C++ namespaces. (Exception: you can add constants from outside, e.g. "scope::newthing = 5")

Yes, I do that a lot.

Quote:
Missing an .endscope or .endproc can have difficult to understand errors, especially affecting preprocessor directives (e.g. the resulting error is commonly "constant expression expected" at some distant place in the code where a global constant has been hidden by the local scope).

I don't think this ever happened to me. Then again, I encapsulate the scope functionality with my own set of macros, and all my code uses these macros in a fairly strict way.

Quote:
Related to previous point, if a symbol is not found in the local scope, it does not automatically check the global scope in some cases.

Yeah, I've been bitten by this. I think it assumes the symbol will be defined within the same scope later, but when it doesn't, shit happens.

Quote:
In assembly I often want to share code between related procedures. Trying to put them all in .proc scopes makes this annoying or ugly.

Yeah, sometimes this is a problem for me too.

Quote:
The required .endproc adds an additional line to every single procedure.

I don't consider this to be a big problem. The reason I don't use .proc is because in many cases I have code both above and below a function's entry point, or functions have multiple entry points. So I made my own macros for creating functions, which can handle those cases.


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 7:17 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5418
Location: Canada
It looks like the latest version of the --dbgfile output does give scope information:
Code:
scope   id=9,name="dScreen",mod=0,type=scope,size=20,parent=0,span=71
seg   id=0,name="CODE",start=0x00F000,size=0x0796,addrsize=absolute,type=ro
sym   id=72,name="name_table",addrsize=absolute,scope=9,def=467,ref=858,val=0xF125,seg=0,type=lab

You'd have to read them separately and paste them together yourself, but the information does appear to be there now.

Edit: Hey it has segments too! Woot! I should really get into this.


Top
 Profile  
 
PostPosted: Mon Dec 05, 2016 10:08 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9793
Location: Rio de Janeiro - Brazil
Cool, will have to look into that! Parsing this file like thefox suggested might indeed be the way to go about this.


Top
 Profile  
 
PostPosted: Tue Jan 03, 2017 1:00 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9793
Location: Rio de Janeiro - Brazil
After some consideration, I decided to continue using scopes for a lot of things, and parse the .dbg file to generate FCEUX .nl files. FCEUX apparently allows "::" in label names, so I can easily "reconstruct" the names of scoped stuff. The .dbg file is a much better place to get all the necessary info for .nl files, since it contains information about the size of the variables and their segments (which unfortunately don't come with the "bank" attribute, but that can be deduced from the offset or from the segment's name), while the VICE label file is just addresses and names.


Top
 Profile  
 
PostPosted: Tue Jan 03, 2017 9:57 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9793
Location: Rio de Janeiro - Brazil
I can't figure out what a "span" is in the .dbg file... It appears one is created for each .res directive, but scopes can also be related to them. Does anyone have any what these actually are?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group