Full assembler listing possible with linked libraries in ca65?
schmidtd
into individual libraries. I have source code to all. They assemble
into .o files, associate into .libs, and then link into the final
product. I have generated assembler listings for individual assembler
files, but of course they have computed/unresolved addresses in the
individual listings.
Short of making a single assembler pass at all files at once, is there
a way to get a symbolic assembler listing (with resolved addresses) of
everything? The .map is helpful, but still requires a lot of fixups
to figure out where code really lives...
David Schmenk
The addresses won't be resolved until the linker generates the final
binary. Link order and the memory config file will define where the
exact resting place will be. Is that what you were asking?
Dave...
John B. Matthews
<2fb93a9e-bc63-41fb...@m45g2000hsb.googlegroups.com>,
schmidtd <schm...@my-deja.com> wrote:
I'm not sure about .lib, but the listing and map files are more
comprehensive if you link statically. Using rod.c as an example:
<http://home.woh.rr.com/jbmatthews/apple2.html#rp1c>
I use this make target to generate .lst and .map:
ROD=rod
...
${ROD}: ${ROD}.c
co65 --code-label _a2e_lo_install a2e.lo.tgi
ca65 a2e.lo.s
cl65 -T -l -O -t apple2enh ${ROD}.c --obj a2e.lo.o --mapfile rod.map
ac -d p1.po ${ROD}
ac -cc65 p1.po ${ROD} bin < ${ROD}
Note -T to get source as comments. Also, consider -S to generate a .s
file with line numbers that match the map.
--
John B. Matthews
trashgod at gmail dot com
home dot woh dot rr dot com slash jbmatthews
schmidtd
> The addresses won't be resolved until the linker generates the final
> binary. Link order and the memory config file will define where the
> exact resting place will be. Is that what you were asking?
Yes, I have the final resting places of all modules (i.e. their
starting addresses/offsets) - but I really want a _listing_ that has
all addresses resolved. Currently, each (sub-)listing ORGs at zero,
so I'd have to do math to figure out the real addresses as loaded.
On Aug 25, 10:39 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> I'm not sure about .lib, but the listing and map files are more
> comprehensive if you link statically. Using rod.c as an example:
> [...]
> Note -T to get source as comments. Also, consider -S to generate a .s
> file with line numbers that match the map.
I'm doing pure assembler, not C - but will check out those options to
see what they offer in my situation.
Thanks!
Bill Buckels
news:2fb93a9e-bc63-41fb...@m45g2000hsb.googlegroups.com...
> is there a way to get a symbolic assembler listing (with resolved
> addresses) of everything? The .map is helpful, but still requires a lot
> of fixups to figure out where code really lives...
You might want to look at Aztec C's OBD output for some ideas on this. A
review of Aztec C's SYM and RSM files that are produced to map overlays and
overlay roots might also be helpful.
Of course as has been already pointed out, and I think you know, the linker
resolves the addresses during the linker pass so I don't know what you are
really asking.
The thought comes to mind that you should write something to read the object
files and create the listing that you want for the occasion.
Bill
schmidtd
disassembler. I can feed it labels and define data areas enough that
I can reverse-engineer a full listing after the fact.
David Schmenk
> On Aug 25, 9:17 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>> The addresses won't be resolved until the linker generates the final
>> binary. Link order and the memory config file will define where the
>> exact resting place will be. Is that what you were asking?
>
> Yes, I have the final resting places of all modules (i.e. their
> starting addresses/offsets) - but I really want a _listing_ that has
> all addresses resolved. Currently, each (sub-)listing ORGs at zero,
> so I'd have to do math to figure out the real addresses as loaded.
>
Gotcha. If you do figure this out, please post. My export list in the
map file is properly located, even though it says RLA next to the
address. But like you say, the source listings aren't resolved.
Dave...
Michael J. Mahon
> On Aug 25, 9:17 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>> The addresses won't be resolved until the linker generates the final
>> binary. Link order and the memory config file will define where the
>> exact resting place will be. Is that what you were asking?
>
> Yes, I have the final resting places of all modules (i.e. their
> starting addresses/offsets) - but I really want a _listing_ that has
> all addresses resolved. Currently, each (sub-)listing ORGs at zero,
> so I'd have to do math to figure out the real addresses as loaded.
That is precisely the reason that I stick to "includes" instead
of linking whenever it's practical.
-michael
AppleCrate II: An Apple II "blade server"!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Michael J. Mahon
But that, of course, loses your comments--which I'm sure are
a very helpful addition to the listing! ;-)
It does seem that someone would have created a tool for "munging"
module listings in the context of a make file and link map to
create a "fully resolved" listing...but it is undoubtedly a
separate step.
This is why I have so far eschewed linking and instead use
include files. Local labels provide a moderate degree of
local name hiding.
schmidtd
> schmidtd wrote:
> > It looks like I can get what I'm after by using da65, the symbolic
> > disassembler. I can feed it labels and define data areas enough that
> > I can reverse-engineer a full listing after the fact.
>
> But that, of course, loses your comments--which I'm sure are
> a very helpful addition to the listing! ;-)
Yeah, there is that. :-)
> It does seem that someone would have created a tool for "munging"
> module listings in the context of a make file and link map to
> create a "fully resolved" listing...but it is undoubtedly a
> separate step.
I thought about doing a text processing exercise, since I could hack
it together quickly - but wanted to play around a bit before embarking
on that.
> This is why I have so far eschewed linking and instead use
> include files. Local labels provide a moderate degree of
> local name hiding.
Me too. The library in question is IP65 - which is a nice, small IP
stack. It's built as separately assembled files, all of which can be
built into a library at link-time, which I did. I can't just inline
everything because of import/export syntax - the assembler barfs on
duplicate labels. When I first started working with it, I hacked it
to pieces so I could get that full listing. Once I got things
working, I pulled it back out and just used the library. Now that I'm
working on the Uthernet card in the ///, I need that listing
again. :-)
My pain was ultimately caused because my map file was inaccurate.
Code simply wasn't where it said it was. I didn't account for the
fact that SOS lops off the first 14 bytes of the executable - and I
had used some assembler chicanery to convince it exactly where the
start address was. Some more chicanery in the linker config file and
all is right with the world. I am ok with doing the math, now that it
produces the right addresses. :-)