search

siliconsam / imp2022

IMP77 compiler for Linux
1 stars 0 forks source link

line numbers in diags #4

Open gtoal opened 1 month ago

gtoal commented 1 month ago

Good that array bound faults are caught, but the line number is wrong (probably a line number from the diags package itself, I guess a little stack unwinding has to be done before the line number is extracted).

Almost everything I'm working on at the moment generates runtime errors but they're no help in locating the problems. Back to the old favourites of inserting print strings.

--

imp2022@linux:~/src/imptests$ imp2022 test.imp
   6 Statements compiled

 ELF object file generated from IMP source file: '/home/imp2022/src/imptests/test.imp'
 +----------+---------------------+---------+---------+---------+------------+
 | Sections |       Symbols       | Code    | Data    | Diag    | Total size |
 +----------+----------+----------+---------+---------+---------+------------+
 |  (count) | Internal | External | (bytes) | (bytes) | (bytes) | (bytes)    |
 +----------+----------+----------+---------+---------+---------+------------+
 |       10 |        5 |        5 |     135 |       0 |      32 |        167 |
 +----------+----------+----------+---------+---------+---------+------------+

imp2022@linux:~/src/imptests$ ./test

**** Arrgh! Last chance event handler triggered from line=427
**** Triggered by error (event,sub,extra)=(6,2,0)
     Error message is 'Array bound fault - Index = 0'

imp2022@linux:~/src/imptests$ cat test.imp
%begin
  %integer %array array(10:20)
  array(15) = 1
  array(0)  = 2
  array(30) = 3
%endofprogram
siliconsam commented 1 month ago

Graham,

Yes, having to add debug messages is a chore which should be minimised. I've had to do that a number of times.

FYI, The line number reported by the event refers to the line number in the imp library routine that detects the error. The line number where the array is accessed (in the actual program before entering the IMP RTL) is not reported or even stored . However, the routine name next reported in the stack trace is where the IMP RTL array access routine is being called from. Unfortunately, the line-number of the call to the IMP RTL routine is not stored in the executable.

Re future plans. So, I really need to add line numbers to the ELF/COFF files (to be added by the pass3elf, pass3coff programs).

Why not use the dwarf mechanism since dwarf is available? I did install a copy of libdwarf but found it too complex for the simple task of storing and reporting line-numbers. Also, it seems libdwarf expects a 64-bit environment for object and executable entities which clashes with IMP77 being a 32-bit environment.

Hence the need for a new and separate line-number storage and reporting mechanism for IMP.

My initial thoughts are that the line numbers would be held in an ELF/COFF section as a set of pairs of (address, line-number) values. Also, the ELF/COFF section would also need to hold the source file name. Routine names are already held in the ELF/COFF section containing the trap table data. It might be possible to merge this line-number data into the ELF/COFF section with the trap table BUT that would mean a mismatch in IMP program versions containing trap tables with/without line-number data. So, my design decision preference would be to use an additional separate ELF/COFF section.

Thus, the event reporting mechanism would use the reported address to map to the line-number of a routine call on the stack and cross index to the routine name (and also source file name) as part of the stack trace. The new event reporting mechanism would need to work even if line-number data is omitted.

I also anticipate that the feature of adding source file, line number data etc to the ELF/COFF section would be an option on the pass3 programs so a module could be compiled with/without line-number info.

Also, it might require 2 versions of the IMP RTL to be available (one without line-number info and one with). And cause an extra wrinkle in the linking stage (i.e. imp32link/i77link etc)

This requires source code changes to:

1. pass3coff 2. pass3elf 3. Various imprtl sources imprtl-event.imp imprtl-trap.imp 4. Various compile + linker scripts Also, a change to the provided ld.i77.script for Linux to add the new section Windows version should cope with the added section if a section naming convention is used similar to that for the trap section.

Any comments?

Once back from holiday, I intend to create a new GitHub repository "imp2024" my modified/updated IMP sources.

1. pass1 It will include unused code in preparation for the grammar changes needed to implement %from ... %include ... It will be encapsulated as an %external %routine It will have a driver program with a simple CLI interface The source code layout will have been changed for source code clarity 2. pass2 Initially it will revert to equating a %short to a %integer It will still include the faulty source used to create %short X86 machine code It will be encapsulated as an %external %routine It will have a driver program with a simple CLI interface The source code layout will have been changed for source code clarity 3. There will be a new driver program which will call pass1 and then pass2 %external %routines It will initially have a simple CLI interface This will allow a transition to a PSR/VAX style CLI interface It will eventually replace the driver programs for pass1, pass2 I note there are other requests re command line options Fine tune the reports generated (switch on/off) * This is aimed at issue#5

     I'll then be able to:-

1. Update the installation process 2. Add the line-number info into the ELF/COFF object files Update the stack trace mechanism 3. Investigate Issue #6 (%result <- feature) Need to check the IMP77 grammar 4. Investigate Issue #7 (string resolution) * I quickly tested your example and same buggy result 5. Hunt down the %short bugs generated by pass2. 6. Add the %from .. %include .. grammar syntax

If I have time over the holiday, I'll look at Issues #6,#7 before including them in the initial release of imp2024

Keep safe + best regards, John McMullin, PhD

From: Graham Toal @.> Sent: Thursday, May 9, 2024 11:00 PM To: siliconsam/imp2022 @.> Cc: Subscribed @.***> Subject: [siliconsam/imp2022] line numbers in diags (Issue #4)

Good that array bound faults are caught, but the line number is wrong (probably a line number from the diags package itself, I guess a little stack unwinding has to be done before the line number is extracted).

Almost everything I'm working on at the moment generates runtime errors but they're no help in locating the problems. Back to the old favourites of inserting print strings.

--

@.***:~/src/imptests$ imp2022 test.imp 6 Statements compiled

ELF object file generated from IMP source file: '/home/imp2022/src/imptests/test.imp' +----------+---------------------+---------+---------+---------+------------+ | Sections | Symbols | Code | Data | Diag | Total size | +----------+----------+----------+---------+---------+---------+------------+ | (count) | Internal | External | (bytes) | (bytes) | (bytes) | (bytes) | +----------+----------+----------+---------+---------+---------+------------+ | 10 | 5 | 5 | 135 | 0 | 32 | 167 | +----------+----------+----------+---------+---------+---------+------------+

@.***:~/src/imptests$ ./test

Arrgh! Last chance event handler triggered from line=427 Triggered by error (event,sub,extra)=(6,2,0) Error message is 'Array bound fault - Index = 0'

@.***:~/src/imptests$ cat test.imp %begin %integer %array array(10:20) array(15) = 1 array(0) = 2 array(30) = 3 %endofprogram

— Reply to this email directly, view it on GitHubhttps://github.com/siliconsam/imp2022/issues/4, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAOZKAN7BF2EQXTKSF2F7PTZBPWWJAVCNFSM6AAAAABHPRWGFWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI4DQNJSHA4TINI. You are receiving this because you are subscribed to this thread.

gtoal commented 1 month ago

A lot to unpack there. One quick note - Imp compilers traditionally have included all checks and diags by default even in production code, and it would be really nice to have the option of a backtrace available, as well as just the filename and line number on an error. Btw dwarf does have a 32-bit interface, it doesn't have to be 64-bit only. Using Elf or Dwarf really would be preferable to adding a private Imp-specific mechanism if at all possible, though historically its true it was all done from Imp as there were no debugging standards back in the 70's. I don't know what the situation was with imp80 on unix though. Maybe there's something to be found in the imp80 code in the archive.

siliconsam commented 1 month ago

Graham, The diagnostic code is already embedded in the compiler, it just needs to be activated by the use of the IMP %diagnostic (although there is a mechanism I added to switch these on via use of a shell variable)

On deep examination of the pass1 source I note there is a %option keyword but this is commented out.

The problem with using Dwarf (even the 32-bit flavour) is that I don't believe it is available for Windows 10/11. I still want to retain a nearly common code base between Windows and Linux.

So, it could mean two different mechanisms for line-numbers. The pass3elf to generate Dwarf and probably a separate event handler set up for Linux The pass3coff to generate the proposed IMP specific line-number section in COFF format and the current event handler updated to access the line data in that COFF section. Hence creating a common IMP specific mechanism to suit both Linux and Windows. NB. An additional COFF/ELF section is already added to store the trap address data utilised in the current stack trace. Using an IMP specific mechanism means that future pass2 versions aimed at different instruction sets and different operating systems (i.e. ARM used in a Raspberry Pi running Linux/RiscOS) would be possible.

I have in mind the VMS operating system ported from VAX to the Intel environment (currently as a virtual machine only). This ported environment is from https://vmssoftware.com/ and has a hobbyist licence validated for 1 year but renewable, I already have a setup on my laptop (as well as the simh version). I may need to save up to get a perpetual licence. I already have VAX Pascal source code to read/write VMS linker data (just need to resurrect an old version of my parser generator that ran on a VAX). This code is inside my simh VAX environment.

As an aside I've cured the string resolution bug Issue #7. When outputting the T in S->("Two").T I didn't allow for the fact of a missing prefix string. This fix is in my interim imp2024 environment on my laptop.

Best regards and keep safe, JD McMullin, Ph.D.

From: Graham Toal @.> Sent: Saturday, May 11, 2024 10:13 AM To: siliconsam/imp2022 @.> Cc: John McMullin @.>; Comment @.> Subject: Re: [siliconsam/imp2022] line numbers in diags (Issue #4)

A lot to unpack there. One quick note - Imp compilers traditionally have included all checks and diags by default even in production code, and it would be really nice to have the option of a backtrace available, as well as just the filename and line number on an error. Btw dwarf does have a 32-bit interface, it doesn't have to be 64-bit only. Using Elf or Dwarf really would be preferable to adding a private Imp-specific mechanism if at all possible, though historically its true it was all done from Imp as there were no debugging standards back in the 70's. I don't know what the situation was with imp80 on unix though. Maybe there's something to be found in the imp80 code in the archive.

— Reply to this email directly, view it on GitHubhttps://github.com/siliconsam/imp2022/issues/4#issuecomment-2105648504, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAOZKAMGLU37DWW3H3JSRX3ZBXOMDAVCNFSM6AAAAABHPRWGFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGY2DQNJQGQ. You are receiving this because you commented.