[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Dodgy addresses in LST xref of COD files
From: Robert Pearce ####@####.#### Date: 22 Apr 2006 16:42:27 +0100 Message-Id: <0yj4WpAS4kSEFw+x@jonah.huneausware.local> I have been having trouble with GPSim not always showing the right bit of the code I'm simulating, and having hacked bits of that before I dived in and dug around. But it turns out not to be a GPSim problem... the COD file lies! I am using gpasm and gplink from v0.13.3 on Gentoo. I have several source files, and some of these source files allocate code into more than one section. For example: tick_isr code incf schPtr,f : : normal code btfsc schTasks,0 : : What I find is that for _some_ of these cases, when linked, the generated COD file declares some lines wrongly in the list file cross-reference. Specifically it seems the very first instruction in a given code section in some files appears with the wrong absolute address. I think the address that appears is the first address of the whole section, where it should be the first address within that section occupied by this file. The second and subsequent instructions are described correctly. I've attached an example file set. Assemble all the .asm files then link using the .lkr (order doesn't matter for this, I just used *.o) and run gpvc on the generated .cod file. The fault should be present on the second instance of "tick_isr code". -- Rob Pearce http://www.bdt-home.demon.co.uk The contents of this | Q: Why do firemen wear red suspenders? message are purely | A: To conform with departmental regulations my opinion. Don't | concerning uniform dress. believe a word. | [Content type application/octet-stream not shown. Download] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |