Subject:
Re: [gnupic] gpsim --"invalid file register" error
From:
Ralph Corderoy ####@####.####
Date:
5 Feb 2007 12:07:07 +0000
Message-Id: <20070205120348.BAD2E1476F8@blake.inputplus.co.uk>
Hi Rob,
> On Sun, 4 Feb 2007, Ralph Corderoy ####@####.#### wrote :
> > I'd want the simulator to perform the check regardless of where the
> > executable came from, so perhaps there wouldn't be a BANKSEL macro?
> > And I normally think of instrumenting code as meaning the code is
> > modified.
>
> Right, so you want it to do this on code that has been loaded without
> source,
Yes.
> meaning it has to work from only the information in the HEX file.
No. :-) As I understand it, at the bottom of the pile you have a HEX
file; the bytes and nothing but the bytes which are to be loaded into
the device.
But above that you can have file formats, e.g. a COFF executable, or
gpsim's COD format, which, in addition to having machine instructions,
have sections containing debug info. This isn't source code, but it is
information gleaned from the source code.
> Or perhaps more relevantly, you want it to work on code compiled from
> something like:
>
> bsf STATUS,RP1
> loop:
> movf indf,w
Yes. I want gpsim to be able to do the run-time check on any suitable
file format that has the required info, gleaned from the source code,
present, e.g. COD. Even if that file was produced by my theoretical m4
+ Python home-grown assembler as opposed to gpasm + gplink.
> But the assembler would have to identify the state of the RP bits at
> 'loop:' which, since it's a label, requires it to identify every
> possible way to reach that label, and if one of those routes has a
> label without any RP settings before it jumps to "loop" then it needs
> to back-track through all that and if one of those.....
>
> Code path static analysis is a phenomenally difficult, complex and
> expensive task.
Yes, can we lay this to rest. Attempting to work out from nothing but
the HEX file what bank the coder intended to be present at a particular
register access is a fool's errand and something I've never proposed and
always argued against. If for no other reason that I may have craftily
worked out that a routine is useful for two purposes depending on which
bank is switched in before I call it. Was that deliberate on my part or
a coding error? No algorithm can tell resulting in false warnings.
> But it's what you're effectively asking for here.
Oh, no I'm not. :-)
> > By binary do you mean the hex file for downloading to the PIC?
>
> Yes, because that may be all GPSim has available.
It *may be* all it has available, in which case gpsim can't do it, just
like it can't do other things if it doesn't have a COD file with extra
information present. We violently agree.
> > I meant an executable file format that can contain debug
> > information. From what little I've read, it seems I mean the COD
> > file for gpsim, e.g. a.cod. That has symbol information, and source
> > references for an opcode's address. Can't a convention be cooked up
> > that allows these to be used to describe the desired bank at a
> > particular address?
>
> The COD file contains that information, which allows GPSim to
> cross-reference the source code and mark the current line.
OK.
> > I'm thinking of "fake" symbols that the coder didn't create. Given
> > an instruction's address, the source file and line number can be
> > found, they can be used to concoct a symbol name, and if that exists
> > then it can contain information lost in translation, e.g. desired
> > selected bank.
>
> Only if that information can be unequivocally determined at build
> time. It is generally accepted that this is not universally possible
> without manual instrumentation of the code.
But I've been arguing for the coder to give that information from my
first post of this subject! Have you come into the thread part way
through? Here it is in a web archive:
http://www.linuxhacker.org/cgi-bin/ezmlm-cgi?1:mss:6252:fdkhhdmkjajgjmpjbcll
> > > The only way for a disassembler to know the coder's intent is to
> > > figure out the state of the RP bits. But that depends on the path
> > > the code has followed to get to that point, so it can't be done
> > > reliably.
> >
> > I agree that's not an option.
>
> But I'm afraid it's the only one available that doesn't require the
> coder to annotate the source.
Which is why I've suggested from day one that the coder pass intent into
the system and have gpsim take note of it for run-time checks.
Cheers,
Ralph.
