From: Groepaz (groepaz_at_gmx.net)
Date: 2002-12-04 11:54:26
On Tuesday 03 December 2002 12:08, Ullrich von Bassewitz wrote:
> There is no documentation available for the object file format used. I do
> not even manage to keep up with the standard compiler docs:-)
:=P figures :=) (everytime i tell someone to use ca65 instead of tass6502 or
some other whacked up program the outdated-docs-thing comes back to me
....ohwell :=P one day i'll update them myself or sth hehehehe :o))
btw speaking of the docs...IMHO there should be a special section "for former
tasm (and simelar) users" that describes how to use ca65 in the most
"tasm-ish" way. (ie, many ppl i have been telling to use ca65 were switching
assemblers not because they were missing features, but because their old
assembler had obscure bugs - and is no more developed for that matter). This
kinda instructions should be most useful for anyone who can't live with
certain limitations that arise because of the assembler+linker approach.
(which can be solved by using one big sourcefile, no external linkage etc)
however, if you would like to add sth like that to the docs, i'd volunteer to
write it ... i can probably cut'n'paste it from my emails anyway :o)
> However, it
> should not be necessary to access the object files, since all information
> that is available in the object files should be collected by the linker and
> output in a special debug file. The debug file is currently somewhat
> incomplete. For one, it does not include labels that are in the label file.
no problem, since i can handle the label-files fine :) actually, since you are
using "external" files for debuginfo anyway, i'd just put some reference to
the labelfile(s) into the debugfile :)
> This will get fixed. Another problem is that the debug file does not
> contain information about local symbols. This information is not available
> in the object file, since for one, the assembler is not able to handle this
> information, second, the compiler does not generate it, and third, it is
> rather difficult to keep this information current over the optimizer
> passes, because the generated code does not use a base pointer, so the
> stack offset of locals may change with every instruction. Because all this
> is unfinished and not really well tested, the option for the linker to
> generate this debug file is undocumented.
well debugging local symbols (ie put watch-/breakpoints on them etc) is even
troublesome in "real" debuggers, atleast if you are using some kind of
optimization during compile... not a big loss to me, i am used to step
through the c-code and watch how registers change at the same time :o)
> --dbgfile name
>
> is what it needs to get such a debug file.
>
> Being able to step through the C source and watching the values of global
> symbols would be tremendously useful, and implementing this is possible
> using the currently available information.
yeah, looks good... i'll start with making my mind up about how to implement
this at ALL hehehe :o) unfortunatly to make this useful i also need either a
working 6510-core (for simulator, cant use marat's core here coz its terms of
use are to restrictive for my taste - and i am way to lazy to dig out my own
and debug that ;=P) or working debug stub (for the real thing, i am working
on that one ;=)) aswell..... (i hate writing loads of code that cannot be
testet immediatly for that matter)
> I would suggest that you
> generate such a debug file and have a look at it. It's straight ASCII, and
> currently it contains just two types of information:
>
> file "crt0.s", 2532, 1038165106
>
> This means that crt0.s is a source file which had 2532 bytes when
> translated, and a time stamp of 1038165106 (unix mtime). The additional
> information can be used to display a warning in the debugger when the
> source code available to the debugger differs from what was available when
> the object file was generated.
>
> line "em_load.c", 58, 00140B-00142F
>
> This means that the code range starting at 140B (hex) up to and including
> 142F (hex) was generated by line 58 of em_load.c. Note that there may be
> more than one entry for the same line of source code. An example would be
> for loops, for which the compiler generates code on loop entry and exit.
>
very nice.... doing some kind of "addr2line" functionality (which is all i
need for a start) shouldnt be a problem with that. (mmmh maybe if cc65 came
with such a tool that could aid other emulator/simulator/debugger/whatnot
writers...allowing them to implement sourcelevel debugging very easy.....)
> There will be some more line types when more information is added, but the
> style will always be the same: The first token on a line is a keyword that
> specifies the type of information that follows.
after a quick peek... i wouldnt mind ALL filenames written by their absolute
pathes. :) (else the debugger for example needs to know about the location of
the library sources). i know this would mean you could no more debug code not
compiled on your machine, but then again thats a rare case anyway. (if you
want to debug library...hell, recompiling it first is recommended anyway
:=)). alternativly you could write the path(es) to search for files into the
debug-file or sth... i like the former idea better though :)
also, i think the file should tell the total memory used by the program (maybe
splitted into bss/code/data etc) so the debugger can use that, and the the
addr2line info for calculating areas for which is no debug-information
available, but which are still code. (is that even a possible scenario incase
of cc65? mmmh)
oh and apropos label files.... is there a way to get ALL labels written there,
not just the exported ones? and what about local labels...there should be a
way to handle these aswell, although that might be kinda hard compared to the
rest :)
ok 'nuff for now.... will prolly take a while until i got something worth
showing (UI coding sux ;=P hehe).
regards
gpz
--
___ ___ .___________________ .___________ _______.
c=64 / | \| \__ ___/ \ \_ _____/ \ \ [groepaz]
gb / ' \ | | | / \ / \ | __)_ / | \ gp32
cgb \ . / | | |/ ' \| \/ | \ psx
gba \___|_ /|___| |____|\____|__ /_______ /\____|__ / dc
-----\/-----'---------------\/--------\/---------\/
http://www.hitmen-console.org Hitmen WWW Headquarters
http://fly.to/hitmen-groepaz my personal playground
http://rr.c64.org/silversurfer home of the RR debugger
ftp.musoftware.de/pub/groepaz cc65 dump site
----------------------------------------------------------------------
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 : 2002-12-04 10:30:21 CET