Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #55879 > unrolled thread

DWARF debugging information, and FORTH

Back to article view | Back to comp.lang.forth

Contents

  DWARF debugging information, and FORTH stoyan.shopov@gmail.com - 2017-03-17 16:20 -0700
    Re: DWARF debugging information, and FORTH rickman <gnuarm@gmail.com> - 2017-03-17 19:55 -0400
      Re: DWARF debugging information, and FORTH hughaguilar96@gmail.com - 2017-03-17 20:31 -0700
        Re: DWARF debugging information, and FORTH stoyan.shopov@gmail.com - 2017-03-18 01:04 -0700
          Re: DWARF debugging information, and FORTH hughaguilar96@gmail.com - 2017-03-18 01:38 -0700
            Re: DWARF debugging information, and FORTH stoyan.shopov@gmail.com - 2017-03-18 04:44 -0700
    Re: DWARF debugging information, and FORTH Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-18 03:51 -0500
    Re: DWARF debugging information, and FORTH Walter Banks <walter@bytecraft.com> - 2017-03-19 19:55 -0400
      Re: DWARF debugging information, and FORTH hughaguilar96@gmail.com - 2017-03-19 17:42 -0700
        Re: DWARF debugging information, and FORTH Walter Banks <walter@bytecraft.com> - 2017-03-20 11:48 -0400
          Re: DWARF debugging information, and FORTH hughaguilar96@gmail.com - 2017-03-20 16:53 -0700
        Re: DWARF debugging information, and FORTH Walter Banks <walter@bytecraft.com> - 2017-03-20 15:13 -0400

#55879 — DWARF debugging information, and FORTH

Hi, All

This is not really a question, just an observation.

I don't really know FORTH too well. I now work for a thermal-printer mechanism manufacturing company. I successfully used FORTH to do our bootloaders for the new chips we use. I also have used FORTH for font processing outside the firmware of our printers, and also for command parsing inside our firmware. Outside work, I have used FORTH for time-sheet processing for a friend of mine, who, unfortunately, is blind. One of my hobbies is making tools, I made some simple printed circuit boards for accessing ARM Cortex-M parts over a serial-wire bus (with the serial-wire-debug - SWD protocol), and I successfully used FORTH for defining the algorithms for flash memory programming of two target chips - STM32F1xx and an STM32f4xx parts.

I am currently trying to write a debugger for ARM Cortex-M chips, because I have been using such parts for maybe 5, or 6 years now, and I feel comfortable with them. Of course, I use the gdb debugger, I am just curious to see if I can streamline my workflow better to my taste, this is just a hobby of mine. I have put my current work here:

https://github.com/stoyan-shopov/troll

I am decoding DWARF debug information in my debugger program.

I just wondered if any of you here have anytime had to decode DWARF debug information?

Thing is, DWARF debug information - 'expressions', are essentially - FORTH. This is not explicitly stated in the DWARF standard, but this standard does explicitly define a stack-machine for performing the computations. It is obvious to me that this is FORTH, and I started writing the DWARF expression evaluation in FORTH.

Also, DWARF stack unwinding - is, essentially, FORTH, I also wrote the stack unwinding in FORTH.

I am just curious, if any of you have ever worked with DWARF debug information - is that FORTH intended, or just came to be so? My bet is it just came to be so, because if you want the simplest way to define an address (or something else), in order to locate something, or do something - is essentially, to make a record of how and what you would do, in order to locate (address) or do that 'something', and if you also want to make this procedure simple and compact - well, it boils down to FORTH 

Not really a question, I am just curious :-)
Please, share your observations and thoughts, it would be interesting! :-)


Greetings from Bulgaria! Be healthy:
stoyan

[toc] | [next] | [standalone]

#55883

On 3/17/2017 7:20 PM, stoyan.shopov@gmail.com wrote:
> Hi, All
>
> This is not really a question, just an observation.
>
> I don't really know FORTH too well. I now work for a thermal-printer mechanism manufacturing company. I successfully used FORTH to do our bootloaders for the new chips we use. I also have used FORTH for font processing outside the firmware of our printers, and also for command parsing inside our firmware. Outside work, I have used FORTH for time-sheet processing for a friend of mine, who, unfortunately, is blind. One of my hobbies is making tools, I made some simple printed circuit boards for accessing ARM Cortex-M parts over a serial-wire bus (with the serial-wire-debug - SWD protocol), and I successfully used FORTH for defining the algorithms for flash memory programming of two target chips - STM32F1xx and an STM32f4xx parts.
>
> I am currently trying to write a debugger for ARM Cortex-M chips, because I have been using such parts for maybe 5, or 6 years now, and I feel comfortable with them. Of course, I use the gdb debugger, I am just curious to see if I can streamline my workflow better to my taste, this is just a hobby of mine. I have put my current work here:
>
> https://github.com/stoyan-shopov/troll
>
> I am decoding DWARF debug information in my debugger program.
>
> I just wondered if any of you here have anytime had to decode DWARF debug information?
>
> Thing is, DWARF debug information - 'expressions', are essentially - FORTH. This is not explicitly stated in the DWARF standard, but this standard does explicitly define a stack-machine for performing the computations. It is obvious to me that this is FORTH, and I started writing the DWARF expression evaluation in FORTH.
>
> Also, DWARF stack unwinding - is, essentially, FORTH, I also wrote the stack unwinding in FORTH.
>
> I am just curious, if any of you have ever worked with DWARF debug information - is that FORTH intended, or just came to be so? My bet is it just came to be so, because if you want the simplest way to define an address (or something else), in order to locate something, or do something - is essentially, to make a record of how and what you would do, in order to locate (address) or do that 'something', and if you also want to make this procedure simple and compact - well, it boils down to FORTH
>
> Not really a question, I am just curious :-)
> Please, share your observations and thoughts, it would be interesting! :-)
>
>
> Greetings from Bulgaria! Be healthy:

Hi Stoyan,

I don't know anything about the history of DWARF.  But I would compare 
it to Postscript, a printer control language which is also stack based 
and interpreted, like Forth.  I guess I don't know if DWARF is 
interpreted or not.

It would appear that Postscript was developed independent of Forth. 
Rather it inherited postfix notation from "The Evans and Sutherland 
Design System" where one of the originators had worked.  The E&S system 
was also token based meaning each word was analyzed before considering 
the next.  While apparently not derived from Forth, it is very Forth-like.

Another system to compare is Open Firmware (or OpenBoot to Sun) pretty 
much *is* Forth but specifically tailored to use as a debug and boot 
program.  You likely are familiar with that.  If not maybe you should 
check it out.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#55884

On Friday, March 17, 2017 at 4:55:59 PM UTC-7, rickman wrote:
> On 3/17/2017 7:20 PM, stoyan.shopov@gmail.com wrote:
> > Hi, All
> >
> > This is not really a question, just an observation.
> >
> > I don't really know FORTH too well. I now work for a thermal-printer mechanism manufacturing company. I successfully used FORTH to do our bootloaders for the new chips we use. I also have used FORTH for font processing outside the firmware of our printers, and also for command parsing inside our firmware. Outside work, I have used FORTH for time-sheet processing for a friend of mine, who, unfortunately, is blind. One of my hobbies is making tools, I made some simple printed circuit boards for accessing ARM Cortex-M parts over a serial-wire bus (with the serial-wire-debug - SWD protocol), and I successfully used FORTH for defining the algorithms for flash memory programming of two target chips - STM32F1xx and an STM32f4xx parts.
> >
> > I am currently trying to write a debugger for ARM Cortex-M chips, because I have been using such parts for maybe 5, or 6 years now, and I feel comfortable with them. Of course, I use the gdb debugger, I am just curious to see if I can streamline my workflow better to my taste, this is just a hobby of mine. I have put my current work here:
> >
> > https://github.com/stoyan-shopov/troll
> >
> > I am decoding DWARF debug information in my debugger program.
> >
> > I just wondered if any of you here have anytime had to decode DWARF debug information?
> >
> > Thing is, DWARF debug information - 'expressions', are essentially - FORTH. This is not explicitly stated in the DWARF standard, but this standard does explicitly define a stack-machine for performing the computations. It is obvious to me that this is FORTH, and I started writing the DWARF expression evaluation in FORTH.
> >
> > Also, DWARF stack unwinding - is, essentially, FORTH, I also wrote the stack unwinding in FORTH.
> >
> > I am just curious, if any of you have ever worked with DWARF debug information - is that FORTH intended, or just came to be so? My bet is it just came to be so, because if you want the simplest way to define an address (or something else), in order to locate something, or do something - is essentially, to make a record of how and what you would do, in order to locate (address) or do that 'something', and if you also want to make this procedure simple and compact - well, it boils down to FORTH
> >
> > Not really a question, I am just curious :-)
> > Please, share your observations and thoughts, it would be interesting! :-)
> >
> >
> > Greetings from Bulgaria! Be healthy:
> 
> Hi Stoyan,
> 
> I don't know anything about the history of DWARF.  But I would compare 
> it to Postscript, a printer control language which is also stack based 
> and interpreted, like Forth.  I guess I don't know if DWARF is 
> interpreted or not.
> 
> It would appear that Postscript was developed independent of Forth. 
> Rather it inherited postfix notation from "The Evans and Sutherland 
> Design System" where one of the originators had worked.  The E&S system 
> was also token based meaning each word was analyzed before considering 
> the next.  While apparently not derived from Forth, it is very Forth-like.
> 
> Another system to compare is Open Firmware (or OpenBoot to Sun) pretty 
> much *is* Forth but specifically tailored to use as a debug and boot 
> program.  You likely are familiar with that.  If not maybe you should 
> check it out.

I don't know anything about DWARF. Just because something like a data-stack is used internally however, doesn't mean that it has anything to do with Forth though. PostScript isn't anything like Forth despite having a data-stack (neither is Factor). OpenBoot had an OOP system that involved passing strings as messages at run-time --- so programming it wasn't anything like programming Forth --- and it was grossly inefficient, which isn't appropriate for a Forth system working on the bare hardware. AFAIK, OpenBoot was designed by Forth Inc. and is another one of their screw-ups --- I remember at the time that Forth Inc. was bragging up their involvement in OpenBoot, but now that it has failed badly I expect that Elizabeth Rather will blame everybody except herself. In the early 1990s OOP was considered to be the silver bullet that slays complexity --- that is no longer believed by anybody --- OOP has its uses, but it sometimes makes for more complexity rather than less.

I wrote a single-step debugger for my 65c02 cross-compiler a long time ago. I wouldn't do that now --- I don't think a single-step debugger is very good for debugging --- this is not how I "streamline my workflow" these days.

Are you programming in GCC for your ARM boards? Even if DWARF uses something like a data-stack internally this doesn't have much to do with Forth. I suppose you could write your debugger in Forth rather than C --- but I don't know of any reason why Forth would be better than C for such a program.

Why don't you program you ARM boards in Forth?

[toc] | [prev] | [next] | [standalone]

#55889

Hi, Hugh


Yes, I am using the gcc compiler, I program in C for my boards.

For the debugger - it runs on the PC, not on the boards - I decided to use the Qt framework, I am using Forth only for DWARF expression evaluation and call-stack unwinding, because it seemed so natural to do so.

As an aside - the DWARF abbreviation officially stands for "Debugging With Attribute Records Format", but that is, I believe, just a pun on ELF - the "Executable and Linkable Format" file format that DWARF was first (in 1991, if I remember correctly) designed to support. DWARF is a method of compact representation of what the compiler did when transforming source code into machine code - such as addresses of variables, locations of parameters of subprograms, line-number information, data types, and so on.

What Forth system can I use, in order to program my ARM boards in Forth? This idea has come to my mind, but last time I checked, I could not find anything providing also support for USB for the chips I am using - stm32f103 and stm32f070. I am just reluctant to code all of the USB stuff myself in Forth, that is the reason I use C, I have libraries there. Besides, I really doubt Forth will be more efficient than C on ARM machines. ARM machines are register-based, not stack oriented.

Yet, I do not really know, never tried to program in Forth on bare metal ARM - if you do have some observations and experience - please share!

Regards,
Stoyan

[toc] | [prev] | [next] | [standalone]

#55891

On Saturday, March 18, 2017 at 1:04:01 AM UTC-7, stoyan...@gmail.com wrote:
> For the debugger - it runs on the PC, not on the boards - I decided to use the Qt framework, I am using Forth only for DWARF expression evaluation and call-stack unwinding, because it seemed so natural to do so.

The way my debugger worked, was that I modified the compiler so it would compile a BRK instruction between every word compiled (whether they were compiled as a JSR or as inline code). The debugger does run on the host machine, as you say. The target program would do a BRK interrupt and that ISR would send all of the pertinent info from the 65c02 over to the MS-DOS machine to be displayed by the debugger.

All of those BRK instructions bloated out the machine-code quite a lot.

I assume that the ARM has some way to throw an interrupt between every instruction. On the 6809, this was accomplished just by setting the timer to a super-short time period (less than any instruction took to execute). This was all a long time ago --- the ARM most likely has some kind of built-in way to interrupt between instructions --- I'm not familiar with these modern processors though.

I'm also not familiar with GUI programming. If you use QT and like it, then that is the way to go. I think VFX has some kind of GUI support --- but you would have to pay for the VFX compiler, which is quite expensive --- QT is free (so long as your program isn't commercial).

[toc] | [prev] | [next] | [standalone]

#55894

Yes, ARMs do have very good support for debugging, and that includes single-instruction execution capabilities. Debug support is very good on ARMs, I think, that is one of the reason they are so popular - everything is documented, no information is hidden. They may not be the best architecture in the universe, but all bits of them are documented, and available to anyone. Really

I don't believe you did all this, it is just too painstaking. Hmm, actually I believe you. I do remember, that back in the 90-s I did single-stepping on my 4.77 MHz PC/XT - an 8088 CPU, single-stepping there does indeed work by generating interrupts, only I was not making debuggers back then, but used single-stepping in order to locate the vectors of crucial interrupts

Doing competent GUI programming, in my experience, is a kind of art, and, to me, difficult to do right. To make a working GUI program is trivial, but to do it right - is art, so it seems to me.

Qt is a very capable and able framework, in my experience. I do not intend to make money from the debugger I try to make, so - yes - it is free for me to use

Regards,
Stoyan

[toc] | [prev] | [next] | [standalone]

#55892

stoyan.shopov@gmail.com wrote:
> 
> Thing is, DWARF debug information - 'expressions', are essentially -
> FORTH. This is not explicitly stated in the DWARF standard, but this
> standard does explicitly define a stack-machine for performing the
> computations. It is obvious to me that this is FORTH, and I started
> writing the DWARF expression evaluation in FORTH.

Right.  There's a sense in which RPN is the only reasonable way to do
it: if you want a compact object code that's simple to execute, it's
the only way to go.  For example, ALGOL was implemented that way, from
the Dijkstra-Zonneveld compiler of 1959-60 onwards.

Andrew.

[toc] | [prev] | [next] | [standalone]

#55953

On 2017-03-17 7:20 PM, stoyan.shopov@gmail.com wrote:
> I am just curious, if any of you have ever worked with DWARF debug
> information - is that FORTH intended, or just came to be so? My bet
> is it just came to be so, because if you want the simplest way to
> define an address (or something else), in order to locate something,
> or do something - is essentially, to make a record of how and what
> you would do, in order to locate (address) or do that 'something',
> and if you also want to make this procedure simple and compact -
> well, it boils down to FORTH
>
> Not really a question, I am just curious :-) Please, share your
> observations and thoughts, it would be interesting! :-)

The biggest difficulty I have found with DWARF (actually ELF / DWARF)
has been the lack of definitive standards and large variation in the
current implementations. To be clear there are standards (several of
them) out there but when it gets to the real details of the described
execution engines I have found when implementing ELF/Dwarf generators
that many details needed to be guessed at and tried with several debuggers.

A lot of the open source tools lose details of the original source
structure. To Hugh's point single stepping at the instruction level
is not worth much be it forth or C. Elf/Dwarf as I have found is fully
capable of being used at the original language level (including stepping
at language statement level) with links back to the source not the
generated code.

w..

[toc] | [prev] | [next] | [standalone]

#55955

On Sunday, March 19, 2017 at 4:55:31 PM UTC-7, Walter Banks wrote:
> A lot of the open source tools lose details of the original source
> structure. To Hugh's point single stepping at the instruction level
> is not worth much be it forth or C. Elf/Dwarf as I have found is fully
> capable of being used at the original language level (including stepping
> at language statement level) with links back to the source not the
> generated code.

What??? You thought I was displaying a disassembly of the generated code? That is only done when the source-code isn't available --- the only people who don't have source-code are software pirates.

My debugger was source-level. As I said before, the compiler compiled a BRK between every Forth word compiled (some compiled as a JSR and others compiled as inline machine-code). The compiler also built a data-base of where all of these BRK instructions were in the machine-code and where the compiler was in the source-code at the time (I used UR/Forth's dictionary to do this; it was a hash-table and was pretty fast). When the BRK occurred on the 65c02 the ISR would send a message over the RS232 to the host and tell it all the pertinent info about the situation (where the BRK was, what the values of the registers were, and what the top few items on the data-stack were). The debugger would then display the source-code with a smiley-face character blinking at the location in the source-code. Also, on the bottom of the screen were displayed the register contents and the top few items on the data-stack. I may have also displayed my local variables --- I can't remember --- that was 25 years ago. I could also set break-points and watch-points, although I didn't use these very much. The whole thing was modeled after Borland Turbo Debugger that I was familiar with at the time.

[toc] | [prev] | [next] | [standalone]

#55967

On 2017-03-19 8:42 PM, hughaguilar96@gmail.com wrote:
> On Sunday, March 19, 2017 at 4:55:31 PM UTC-7, Walter Banks wrote:
>> A lot of the open source tools lose details of the original source
>> structure. To Hugh's point single stepping at the instruction
>> level is not worth much be it forth or C. Elf/Dwarf as I have found
>> is fully capable of being used at the original language level
>> (including stepping at language statement level) with links back to
>> the source not the generated code.
>
> What??? You thought I was displaying a disassembly of the generated
> code? That is only done when the source-code isn't available --- the
> only people who don't have source-code are software pirates.
>
> My debugger was source-level. As I said before, the compiler compiled
> a BRK between every Forth word compiled (some compiled as a JSR and
> others compiled as inline machine-code). The compiler also built a
> data-base of where all of these BRK instructions were in the
> machine-code and where the compiler was in the source-code at the
> time (I used UR/Forth's dictionary to do this; it was a hash-table
> and was pretty fast). When the BRK occurred on the 65c02 the ISR
> would send a message over the RS232 to the host and tell it all the
> pertinent info about the situation (where the BRK was, what the
> values of the registers were, and what the top few items on the
> data-stack were). The debugger would then display the source-code
> with a smiley-face character blinking at the location in the
> source-code. Also, on the bottom of the screen were displayed the
> register contents and the top few items on the data-stack. I may have
> also displayed my local variables --- I can't remember --- that was
> 25 years ago. I could also set break-points and watch-points,
> although I didn't use these very much. The whole thing was modeled
> after Borland Turbo Debugger that I was familiar with at the time.
>

At its lowest level ELF/DWARF has instruction level information to
execute an instruction at a time. There is also can be information to
step at the level of the source code statements.

As I pointed out in the original post definition and implementation
issues are a problem in source level debugging with ELF/DWARF. It
certainly is widely used.

Current debugger technology doesn't generally used compiled in
statement delimiters (like BRK) even ion code executing from ROM.

w..

[toc] | [prev] | [next] | [standalone]

#55980

On Monday, March 20, 2017 at 8:48:55 AM UTC-7, Walter Banks wrote:
> On 2017-03-19 8:42 PM, hughaguilar96@gmail.com wrote:
> > On Sunday, March 19, 2017 at 4:55:31 PM UTC-7, Walter Banks wrote:
> >> A lot of the open source tools lose details of the original source
> >> structure. To Hugh's point single stepping at the instruction
> >> level is not worth much be it forth or C. Elf/Dwarf as I have found
> >> is fully capable of being used at the original language level
> >> (including stepping at language statement level) with links back to
> >> the source not the generated code.
> >
> > What??? You thought I was displaying a disassembly of the generated
> > code? That is only done when the source-code isn't available --- the
> > only people who don't have source-code are software pirates.
> >
> > My debugger was source-level. As I said before, the compiler compiled
> > a BRK between every Forth word compiled (some compiled as a JSR and
> > others compiled as inline machine-code). The compiler also built a
> > data-base of where all of these BRK instructions were in the
> > machine-code and where the compiler was in the source-code at the
> > time (I used UR/Forth's dictionary to do this; it was a hash-table
> > and was pretty fast). When the BRK occurred on the 65c02 the ISR
> > would send a message over the RS232 to the host and tell it all the
> > pertinent info about the situation (where the BRK was, what the
> > values of the registers were, and what the top few items on the
> > data-stack were). The debugger would then display the source-code
> > with a smiley-face character blinking at the location in the
> > source-code. Also, on the bottom of the screen were displayed the
> > register contents and the top few items on the data-stack. I may have
> > also displayed my local variables --- I can't remember --- that was
> > 25 years ago. I could also set break-points and watch-points,
> > although I didn't use these very much. The whole thing was modeled
> > after Borland Turbo Debugger that I was familiar with at the time.
> >
> 
> At its lowest level ELF/DWARF has instruction level information to
> execute an instruction at a time. There is also can be information to
> step at the level of the source code statements.
> 
> As I pointed out in the original post definition and implementation
> issues are a problem in source level debugging with ELF/DWARF. It
> certainly is widely used.
> 
> Current debugger technology doesn't generally used compiled in
> statement delimiters (like BRK) even ion code executing from ROM.
> 
> w..

I wrote that 25 years ago for the 65c02 which is pretty primitive compared to modern processors. I'm not saying that my use of compiled-in BRK instructions is state-of-the-art. It bloats out the machine-code a lot. Also, it slows down the execution. After I tested the low-level functions, I would turn off the debugging (compilation of BRK) for them. This way the single-stepper would step over them as if they were primitives even though they were colon definitions.

Anyway, the point that I'm making, is that I wrote that debugger when I was still a novice at Forth programming. I was just doing C-style debugging in Forth. I don't think debuggers are useful now. Even with ICE which is quite fast, they are a big waste of time because they require you to execute your entire program. These days I prefer traditional interactive Forth debugging at a REPL. This way I can test a single function in isolation, giving it various parameters. Forth is all about bottom-up development, not top-down development.

Back in the late 1980s and early 1990s, ICE and SoftICE were a big deal. That is not true anymore. Nowadays everybody debugs interactively at a REPL --- in those days, only Forth and Lisp had this feature --- now we have multiple languages, mostly Lisp-derived, that have this feature.

[toc] | [prev] | [next] | [standalone]

#55972

On 2017-03-19 8:42 PM, hughaguilar96@gmail.com wrote:
> On Sunday, March 19, 2017 at 4:55:31 PM UTC-7, Walter Banks wrote:
>> A lot of the open source tools lose details of the original source
>> structure. To Hugh's point single stepping at the instruction
>> level is not worth much be it forth or C. Elf/Dwarf as I have found
>> is fully capable of being used at the original language level
>> (including stepping at language statement level) with links back to
>> the source not the generated code.
> What??? You thought I was displaying a disassembly of the generated
> code? That is only done when the source-code isn't available --- the
> only people who don't have source-code are software pirates.

Actually I have no idea what you were displaying. Single stepping
implied to me instruction stepping.

ELF/DWARF with the right type of support tools and correct description
of the generated code can be very useful on debugging complex pieces of
application code.

With the right type of support code metrics logging, implied print
statements, complex break points that only stops execution when some
logical expression is met is all possible.

w..

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web