[M3devel] debugging with stock gdb
Daniel Alejandro Benavides D.
dabenavidesd at yahoo.es
Wed Sep 1 23:53:33 CEST 2010
Hi all:
Yes I think this might be useful specially debugging when no stock m3gdb available.
I wanted to also consider this case
you have great disassemblers, debuggers and plenty of useful tools for easier debugging. If you could do that would be great for all the developers planning transition to Modula-3 from other languages. But thinking in the core developers testers, users as you have seen probably the best resource at hand even in the case there are better ones is just to keep the new environment enhancing and porting.
Most of code debuggers are written from runtime environments so the advantage would be cumbersome because we need also a lot of tools to keep track of all variety of this third party tools distributors.
Also if in such an effort you can actually test changes in fewer platforms.
In the other case would be newer things to ask and use on the new stock debugger.
So keeping the changes in this way will get more of the same characteristics at some level less or more but in the end you will you would just have to keep an effort in the same way, not too many in a lot of different ways certainly.
By the end of the day it will be just less output for the same work and as a contrast more output for same work, so a lot easier if not new things were added.
A wanted feature might be a less harder work to port to new system, this was achieved using the native code generators but this was a lot of effort to put it to work still.
I guess this efforts could be later enhanced for the good of the native platform and others also.
In other projects efforts are working towards that end, like openwatcom. As being openned they have more customers, users and developers with different needs and they are working to adapt their system to that. Perhaps no with the same effort to put it to work in other systems but certainly to their system that's an useful advantage to host more users with same system
Probably this kind of systems doesn't allow too much new tools if they want to maintain the user base, but they wanted and have to move forward with new ones.
As a result the system is enhanced but the cost or effort could be less than the actual to get a new runtime environment to work in top of it.
Main thing here was to try to save some time in getting user and easily adapted to your users, but you have spent more time in that case for that thing than keeping up to date of others. So you might wonder how this might happen.
Well in such a case we need a little more of illustration we can take advantage of a useful paper to look for standing with the challenges that anyway come like this side effect of independent works of related efforts or works and so much of the forks and third party options and distributions.
This might be a penalty for this customer base but how it would if they were not there for us? well it might interesting to have a read of
https://168.176.86.16/~danielb/Taking_control.pdf (just accept security domain error and add security exception to download it)
This resumes some techniques useful for this kind of tricky questions, downloaded from:
http://ciozone.madisonlogic.com/black_duck_software/
You will need to fill a survey.
Well that's all I have in mind well and a last long ago sentence from a paper "The Modula-3 compiler generates the intermediate code of the GNU compiler. Therefore, any system that can run GNU C can run Modula-3"
p. 28
in http://www.liacs.nl/~llexx/APPARC/DELIVERABLES/PME4a.ps.gz
I guess that is not the same case for the symbols of the new stock debugger, what do you think?
Thanks in advance
--- El mié, 1/9/10, Jay K <jay.krell at cornell.edu> escribió:
> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] debugging with stock gdb
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: miércoles, 1 de septiembre, 2010 11:30
>
> Here's a quick sample of what you can do now in gdb, so
> much better than before.
> Records used to have no types.
> This is on Darwin.
>
>
> jbook2:m3cc jay$ gdb /cm3/bin/Juno
> GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10
> 02:43:13 UTC 2009)
>
> (gdb) break RTType__Expand
> (gdb) run
> Breakpoint 1, RTType__Expand (M3_DaARCY_m=0x1010cccd0) at
> ../src/runtime/common/RTType.m3:715
> 715 new : InfoMap;
> (gdb) n
> 716 pi, pt: SlotPtr;
> (gdb) n
> 719 IF m.map = NIL THEN
> (gdb)
> 721 m.cnt := 0;
> (gdb) info locals
> M3_AcxOUs_key2 = 4312105936
> M3_AcxOUs_key1 = 4321920593
> M3_EM4UH1_pt = (struct {...} ***) 0x0
> M3_EM4UH1_pi = (struct {...} ***) 0x0
> M3_BQo8Jp_new = {
> name = 0x0,
> is_equal = 0x0,
> rehash = 0x0,
> initial_size = 0,
> full = 0,
> cnt = 0,
> max = 0,
> mask = 0,
> map = 0x0
> }
> (gdb) p **M3_DaARCY_m
> $1 = {
> name = 0x1010e2ca0,
> is_equal = 0x8,
> rehash = 0x7364697565707974,
> initial_size = 0,
> full = 2,
> cnt = 4312673440,
> max = 6,
> mask = 126875185803874,
> map = 0x2
> }
>
>
> - Jay
>
>
>
>
More information about the M3devel
mailing list