gnupic: Thread: gplink lst

Is there a way to turn off listing generation for gplink?

There is a bug in there that forces gplink to emit an error that
source was not found, when linking with a library and the library's
source file is not in the current directory.

Regards,
Vangelis Rokas

On Sun, 2004-02-15 at 06:52, Vangelis Rokas wrote:
> Is there a way to turn off listing generation for gplink?
> 

There isn't right now, but I can add it.  Do we want it to default to ON
or OFF?  Any opinions about the gplink list output?  I have grown to
like it.  Especially for high level languages.  I don't think I
announced it on this list and I should have.

Here it goes.

As of 0.12.0, gplink generates a total list file.  The file shows the
final machine code after all the sections have been relocated and
patched.

To improve gputils support for high level languages, two debug
directives, #line and #file, have been added to gpasm.  These directives
cause gpasm to create user defined COFF lines numbers in the object
file.  When used correctly, they should allow for source level debugging
of any language.  This is intended to be a replacement for the temporary
;#CSRC comments in SDCC's output.

gpal is the only tool which inserts these directives so far.  They cause
gplink to generate a list file like this:


gplink-0.12.0 alpha
Copyright (c) 1998-2004 gputils project
Listing File Generated: 2-15-2004  12:08:09
 
 
Address  Value    Disassembly              Source
-------  -----    -----------              ------
                                           module main is
                                           
                                             procedure main is
                                             
                                               i : uint8;
                                             
                                             begin
                                             
000005   3000     movlw	0                      i = 0;
000006   00a0     movwf	0x20               
                                           
                                               loop
000007   0820     movf	0x20, w                   i = i + 5;
000008   3e05     addlw	0x5                
000009   00a0     movwf	0x20               
00000a   2807     goto	0x7                 
00000b   0008     return                   
                                               end loop;
                                             
000000   118a     bcf	0xa, 0x3             end procedure;
000001   120a     bcf	0xa, 0x4             
000002   2805     goto	0x5                 
                                           
                                           end module;

You can clearly see the instructions that gpal uses.  This demonstrates
that gpal is somewhat functional, but not optimal right now.  A few more
late nights should fix that.

Because gplink's COD output uses information from the COFF file, gpsim
will see the same source line numbers.  So hopefully, you can step
through the source file files (.pal) instead of the intermediate files
(.asm).  This part isn't quite working yet, but it is close. 

> There is a bug in there that forces gplink to emit an error that
> source was not found, when linking with a library and the library's
> source file is not in the current directory.
> 

That is a bug that should be fixed regardless of the list file control. 
I seem to remember thinking of this, it must have missed my TODO list. 
I will take care of it.

> Regards,
> Vangelis Rokas
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

On 15 Feb 2004, Craig Franklin wrote:

> To improve gputils support for high level languages, two debug
> directives, #line and #file, have been added to gpasm.  These directives
> cause gpasm to create user defined COFF lines numbers in the object
> file.  When used correctly, they should allow for source level debugging
> of any language.  This is intended to be a replacement for the temporary
> ;#CSRC comments in SDCC's output.


I look forward to replacing the parsing of ;#CSRC comments in gpsim.

I also need to get familiar with the linker. One question I've been 
meaning to ask is how hard would it be to add a #assert directive to 
gpasm? One of the arguments against it would be the lost of MPASM 
compatibility. But the idea is that one could write:

#assert  expression

The expression would be passed through the assembler, through the linker
and all the way to the simulator. The assertion is a simulation assertion
(as opposed to a run-time assertion, which I presume is not too useful in
a microcontroller), and will allow users to create sanity checks in their
code. Here's an example:

   ; 5-instruction 16-bit add, ignore carry out

      MOVF   A_lo,W
      ADDWF  B_lo,F
#assert  (known_zero == 0)
      RLF    known_zero,W	;pick up carry
      ADDWF  A_hi,W
      ADDWF  B_hi,F

The simulator will parse either the .cod or .coff file and turn the 
assertions into condition break points.

Scott

On Sun, 2004-02-15 at 12:57, Scott Dattalo wrote:
> I also need to get familiar with the linker. One question I've been 
> meaning to ask is how hard would it be to add a #assert directive to 
> gpasm? One of the arguments against it would be the lost of MPASM 
> compatibility. But the idea is that one could write:
> 
> #assert  expression
> 
> The simulator will parse either the .cod or .coff file and turn the 
> assertions into condition break points.
> 

I was going to bring up that issue too.  I need assertions for automated
testing of gpal and didn't know if gpsim had that capability.

Passing the expressions through a COD or COFF file would be a
challenge.  I was thinking about creating an assertion library to link
my gpal outputs against.  Then tell gpsim to emit an error if the
program counter == the assert procedure.  In a simple case, gpsim can
look at the stack to see where the last call came from to know what
generated the error. In a more complicated case, the compiler could
generate machine code to evaluate the assert expressions if debug was
enabled.

> Scott

On 15 Feb 2004, Craig Franklin wrote:

> On Sun, 2004-02-15 at 12:57, Scott Dattalo wrote:
> > I also need to get familiar with the linker. One question I've been 
> > meaning to ask is how hard would it be to add a #assert directive to 
> > gpasm? One of the arguments against it would be the lost of MPASM 
> > compatibility. But the idea is that one could write:
> > 
> > #assert  expression
> > 
> > The simulator will parse either the .cod or .coff file and turn the 
> > assertions into condition break points.
> > 
> 
> I was going to bring up that issue too.  I need assertions for automated
> testing of gpal and didn't know if gpsim had that capability.
> 
> Passing the expressions through a COD or COFF file would be a
> challenge.  I was thinking about creating an assertion library to link
> my gpal outputs against.  Then tell gpsim to emit an error if the
> program counter == the assert procedure.  In a simple case, gpsim can
> look at the stack to see where the last call came from to know what
> generated the error. In a more complicated case, the compiler could
> generate machine code to evaluate the assert expressions if debug was
> enabled.

Well, the way you're describing it, gpsim already has the capability. In 
fact, I did something similar for this for the SDCC regression tests. What 
I'm describing now however, is something much less intrusive to the source 
code. The idea is that the assertion is only valid for simulation. Thus, 
for production code (or whatever) you'd leave the assertions in knowing 
that no assertion code will get programmed into the real part. This is 
also useful for performing automatic regression tests. For example, you 
could imagine one code base being using for several projects. A script 
could be written to check code out of CVS, build one of the particular 
applications, perform a regression test, etc. This way, you could fairly 
easily determine if a change made for one application adversely affects 
another.

BTW, if you look in the SDCC code base at the directory sdcc/regression/* 
you'll find the regression code that I wrote. Of particular interest are 
the regression test scripts. I also started something similar in gpsim in 
the regression/ directory. This code is only in CVS

http://cvs.sourceforge.net/viewcvs.py/gpsim/regression/


I recall something about .cod files reserving special blocks for 
simulation. I'd assume that .coff files would have some other similar 
mechanism. If there is then we can use it (or abuse it) for assertions. If 
not, we could we possibly extend the .coff definition for our own 
application?

Scott

On Sun, 2004-02-15 at 14:27, Scott Dattalo wrote:
> Well, the way you're describing it, gpsim already has the capability. In 
> fact, I did something similar for this for the SDCC regression tests. What 

I thought you had, but I hadn't taken the time to look.

> I'm describing now however, is something much less intrusive to the source 
> code. The idea is that the assertion is only valid for simulation. Thus, 

Both methods require assert statements.  So the source code wouldn't be
very different.

> for production code (or whatever) you'd leave the assertions in knowing 
> that no assertion code will get programmed into the real part. This is 

Valid point, but I was thinking the machine code part was optional.  The
benefit would be if you needed runtime checks you would have it.

> also useful for performing automatic regression tests. For example, you 
> could imagine one code base being using for several projects. A script 
> could be written to check code out of CVS, build one of the particular 
> applications, perform a regression test, etc. This way, you could fairly 
> easily determine if a change made for one application adversely affects 
> another.
> 

Agree on its usefulness, that is why I was looking for a gpal solution.

> BTW, if you look in the SDCC code base at the directory sdcc/regression/* 
> you'll find the regression code that I wrote. Of particular interest are 
> the regression test scripts. I also started something similar in gpsim in 
> the regression/ directory. This code is only in CVS
> 
> http://cvs.sourceforge.net/viewcvs.py/gpsim/regression/
> 
> 

I will look at it.

> I recall something about .cod files reserving special blocks for 
> simulation. I'd assume that .coff files would have some other similar 
> mechanism. If there is then we can use it (or abuse it) for assertions. If 
> not, we could we possibly extend the .coff definition for our own 
> application?
> 

I am not sure about the COD, but adding data to the COFF isn't a
problem.  We can add our own COFF debug symbols, but gpsim doesn't read
COFF files yet.

As I stated before, I think storing the expressions might be an issue. 
Unless you want me to pass the raw text and let gpsim parse the
expressions.

> Scott
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>