From rodney_bates at lcwb.coop Thu Jun 3 21:41:00 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 3 Jun 2021 14:41:00 -0500 Subject: [M3devel] g++9 and g++-8 undermine debugging In-Reply-To: References:

Message-ID: The problem is: 1) m3gdb will not handle position-independent executables that have debug info in stabs format. (Neither will recent gdb versions.) 2) gcc, when linking, has recently changed its default from -no-pie to -pie, the latter producing a position-independent executable. So, -no-pie on the link step gets things back the way they were. On 5/21/21 12:53 PM, Jay K wrote: > Been over 10 years. > > commit d61ee80f9391bf4eaa1f02aa9c306d7d2039a7c1 > Author: Jay Michael Krell > Date: ? Tue Aug 24 05:24:24 2010 +0000 > > ? ? restor all the code for generating main not in C > > commit 1b57d6ed7649dcf6133ba65f202e2789920cba7e > Author: Jay Michael Krell > Date: ? Mon Aug 23 05:51:23 2010 +0000 > > ? ? Always generate main in C. > > My bet is more on gas, but it is worth a try. > > Do breakpoints in .so files work? They are not affected by this I think. > > ?- Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Rodney M. Bates > *Sent:* Friday, May 21, 2021 3:46 PM > *To:* Jay K ; m3devel ; rodney.m.bates at acm.org > *Subject:* Re: [M3devel] g++9 and g++-8 undermine debugging > > > On 5/21/21 9:54 AM, Rodney M. Bates wrote: >> >> >> On 5/19/21 6:47 PM, Jay K wrote: >>> Thank you for the thoroughness. >>> There was another factor I think you missed, which is _m3main.c can be C, or we can skip C and go right to m3cg. >>> One of my peeves is unnecessary options and matrix expansion, and resulting lack of testing and extra work, so I years ago changed either the config or builder to always generate the C. Arguably, pedantically, this also improves C++ compatibility -- on ancient systems main needs to be in C++ to run static constructors, but nothing works that way these days, probably only cfront. >>> >>> The old code is definitely still there. >>> Try it? >> >> I found MxGen.GenerateMain,which will do it either way, but >> no calls on it except in Builder.GenerateCMain, which unconditionally >> does it in C and is called unconditionally from Builder.BuildProgram. >> It looks like some glue code is gone to test which way and to provide >> and use the needed cg_output:M3CG.T to pass to GenerateMain.? There are >> instances of "M3_MAIN_IN_C = TRUE" in config files, but I find no uses >> anywhere in m3-sys. >> >> Can you point me to a commit that has what's needed? > > I found it in an old tree on my local disk.? Not yet sure how > minimal a reinstatement I can get by with, but the needed > stuff is there. > >> >>> At least for experimental data? >>> You know, I mean, I have no idea what is the problem, and if this will fix it, but if it is does, that will be very useful as a workaround and optionally to understand the problem. >>> >>> Understand that the gcc developers have a passive/aggressive attitude toward stabs. >>> I think gcc retains support, only really for AIX. >>> But further note that gcc support for stabs..we don't really need anyway. >>> We only need the assembler and linker to work with them. (Well, I don't...) >>> Perhaps the assembler/linker developers have a similar attitude, and perhaps, really, the problem is in them. >>> >>> Can you control for gas? >>> i.e. Can you try with old gas? Or trunk gas? Or clang's assembler? >>> Gas is a common factor here across gcc and clang and may explain that surprise. >>> >>> Aside: I did find a bug in clang's assembler, that affected probably nobody but us/me, on MacOSX, when targeting older systems. >>> That caused crashing (not debugging related). >>> I put a workaround in our gcc fork. >>> Specifically, it had to do with matching up imported functions and their stubs/pointers. >>> Clang's assembler assumes they are in corresponding order, and I guess ignores their names. >>> Gcc outputs them in hash order. >>> So the result was the assembler producing incorrect code. >>> I changed our gcc to sort them or something. >>> When targeting newer MacOSX I think you don't output the stuff and the linker synthesizes them. >>> Besides that people don't target old MacOSX, people don't often send gcc's output to clang assembler. (MacOSX only has clang asssembler, at least from Apple, ignoring Homebrew). >>> >>> Can you copy the .o files from the working system, then gcc/link + m3gdb on new? >>> >>> ??- Jay >>> >>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >>> *From:* Rodney M. Bates >>> *Sent:* Wednesday, May 19, 2021 10:21 PM >>> *To:* Jay K ; m3devel ; rodney.m.bates at acm.org >>> *Subject:* Re: [M3devel] g++9 and g++-8 undermine debugging >>> These cases are on two machines with different linux distributions. >>> >>> Compiling on the old machine, with older g++/gcc(5.4.0) and with older >>> clang++/clang (3.8.0), all cases work. >>> >>> On the new machine, newer g++/gcc (9.3.0) and newer clang++/clang >>> (10.0.0), all cases fail. >>> >>> In all cases, with/without the ++ makes no difference.? clang >>> or gcc makes no difference.? -g/-gstabs+ makes no difference. >>> >>> It is the same cm3 executable on both.? The .o file for the one >>> M3 module is the same size, but has different cksum.? However, >>> objdump --full-contents on them gives identical text files. >>> Probably a compilation time/date.? The compiled _m3main.o and prog >>> vary.? All other intermediate files are identical, especially >>> _m3main.c >>> >>> Those cases that fail all give the same address where the debugger >>> was unable to insert a breakpoint at: 0x9ad.? Tedious debugging of >>> m3gdb using gdb on a succeeding case had 0xa585c for the break >>> address.? This value is called a displacement in internal >>> variables. >>> >>> The age of the C/C++ compiler seems to be the only variable that >>> makes a difference.? Odd that g++ and clang++ should track each >>> other on this. >>> >>> On 5/18/21 7:31 PM, Jay K wrote: >>>> Can you elaborate on the matrix? >>>> >>>> gcc vs. g++ vs. clang vs. clang++ ? >>>> ? ? Do any of them work? >>>> >>>> -g vs. -gstabs vs. other forms of -g? >>>> ? ? Does anything work? >>>> >>>> "main in C" or not? >>>> ? ? Does anything work? >>>> I changed "it", I forgot, config or builder, so main is always in C, but I didn't remove the old code, so maybe try the other? >>>> >>>> Can gdb or lldb debug the C code? >>>> ? ?I realize that might not matter. >>>> >>>> I assume g++ -g/-gstabs/etc. on non-Modula3 hello world works for you? >>>> (well, some versions of -gstabs do have problems with C, but not what you describe.) >>>> >>>> ? ?- Jay >>>> >>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >>>> *From:* M3devel on behalf of Rodney M. Bates >>>> *Sent:* Wednesday, May 19, 2021 12:21 AM >>>> *To:* m3devel >>>> *Subject:* [M3devel] g++9 and g++-8 undermine debugging >>>> g++9, from experimental evidence, is doing something to _m3main.o >>>> that gives m3gdb bad code addresses.? m3gdb tries to insert breakpoints >>>> at invalid addresses and fails.? This is for breakpoints in m3-compiled >>>> code, not in _m3main itself. >>>> >>>> g++-8 also fails. >>>> >>>> g++5 is what I have used previously, and it works. These are the only >>>> ones I have tried and can easily try. >>>> >>>> -- >>>> Rodney Bates >>>> rodney.m.bates at acm.org >>>> _______________________________________________ >>>> M3devel mailing list >>>> M3devel at elegosoft.com >>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C8d3aca28c5fb45bf666508d91c6faa4e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637572088185808901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zPuBGdIRMAsp4wiTodVe74Uz8bQ1yWzhP6iQih9VlNE%3D&reserved=0 > > >>> >> >>>> >>>> _______________________________________________ >>>> M3devel mailing list >>>> M3devel at elegosoft.com >>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C8d3aca28c5fb45bf666508d91c6faa4e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637572088185818891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DDpsBQImEqoqtR0AM87AclkmaEKcQSij5x9pQfadYts%3D&reserved=0 > > >>>> >>> >>> -- >>> Rodney Bates >>> rodney.m.bates at acm.org >>> >>> _______________________________________________ >>> M3devel mailing list >>> M3devel at elegosoft.com >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C8d3aca28c5fb45bf666508d91c6faa4e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637572088185818891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DDpsBQImEqoqtR0AM87AclkmaEKcQSij5x9pQfadYts%3D&reserved=0 >>> >> > > -- > Rodney Bates > rodney.m.bates at acm.org > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From vvm at tut.by Fri Jun 4 09:03:06 2021 From: vvm at tut.by (vvm at tut.by) Date: Fri, 04 Jun 2021 10:03:06 +0300 Subject: [M3devel] m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: g++9 and g++-8 undermine debugging In-Reply-To: References:

Message-ID: <2016441622789872@mail.yandex.by> An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jun 4 18:24:01 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 4 Jun 2021 16:24:01 +0000 Subject: [M3devel] m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: g++9 and g++-8 undermine debugging In-Reply-To: <2016441622789872@mail.yandex.by> References:

, <2016441622789872@mail.yandex.by> Message-ID: "We" should try to fix m3gdb. PIE exists for a good reason, security. At least make the no-pie specific to m3cc since stabs and m3gdb are specific to it. - Jay ________________________________ From: vvm at tut.by Sent: Friday, June 4, 2021 12:03:06 AM To: rodney.m.bates at acm.org ; Jay K ; m3devel Subject: m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: [M3devel] g++9 and g++-8 undermine debugging Hi! I.e. this ( see later) can solve problem? == --- AMD64_LINUX 000 Thu May 20 12:11:48 2021 +++ AMD64_LINUX Thu Jun 03 17:19:50 2021 @@ -1,10 +1,14 @@ readonly TARGET = "AMD64_LINUX" % code generation target readonly GNU_PLATFORM = "amd64-linux" % "cpu-os" string for GNU -SYSTEM_CC = "gcc -g -m64 -fPIC" % C compiler -SYSTEM_CXXC = "g++ -g -m64 -fPIC" % C++ compiler +SYSTEM_CC = "gcc -gdwarf-2 -gstrict-dwarf -m64" % C compiler +SYSTEM_CXXC = "g++ -gdwarf-2 -gstrict-dwarf -m64" % C++ compiler readonly SYSTEM_ASM = "as --64" % Assembler + +% PIE debugging requires gdb 7.1 or newer, even for C +% see http://www.gnu.org/software/gdb/download/ANNOUNCEMENT +readonly POSITION_INDEPENDENT_EXECUTABLE = "-no-pie" include("AMD64.common") include("Linux.common") == Best regards, Victor Miasnikov 03.06.2021, 22:41, "Rodney M. Bates" : The problem is: 1) m3gdb will not handle position-independent executables that have debug info in stabs format. (Neither will recent gdb versions.) 2) gcc, when linking, has recently changed its default from -no-pie to -pie, the latter producing a position-independent executable. So, -no-pie on the link step gets things back the way they were. On 5/21/21 12:53 PM, Jay K wrote: Been over 10 years. commit d61ee80f9391bf4eaa1f02aa9c306d7d2039a7c1 Author: Jay Michael Krell > Date: Tue Aug 24 05:24:24 2010 +0000 restor all the code for generating main not in C commit 1b57d6ed7649dcf6133ba65f202e2789920cba7e Author: Jay Michael Krell > Date: Mon Aug 23 05:51:23 2010 +0000 Always generate main in C. My bet is more on gas, but it is worth a try. Do breakpoints in .so files work? They are not affected by this I think. - Jay ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* Rodney M. Bates > *Sent:* Friday, May 21, 2021 3:46 PM *To:* Jay K >; m3devel >; rodney.m.bates at acm.org > *Subject:* Re: [M3devel] g++9 and g++-8 undermine debugging On 5/21/21 9:54 AM, Rodney M. Bates wrote: On 5/19/21 6:47 PM, Jay K wrote: Thank you for the thoroughness. There was another factor I think you missed, which is _m3main.c can be C, or we can skip C and go right to m3cg. One of my peeves is unnecessary options and matrix expansion, and resulting lack of testing and extra work, so I years ago changed either the config or builder to always generate the C. Arguably, pedantically, this also improves C++ compatibility -- on ancient systems main needs to be in C++ to run static constructors, but nothing works that way these days, probably only cfront. The old code is definitely still there. Try it? I found MxGen.GenerateMain,which will do it either way, but no calls on it except in Builder.GenerateCMain, which unconditionally does it in C and is called unconditionally from Builder.BuildProgram. It looks like some glue code is gone to test which way and to provide and use the needed cg_output:M3CG.T to pass to GenerateMain. There are instances of "M3_MAIN_IN_C = TRUE" in config files, but I find no uses anywhere in m3-sys. Can you point me to a commit that has what's needed? I found it in an old tree on my local disk. Not yet sure how minimal a reinstatement I can get by with, but the needed stuff is there. At least for experimental data? You know, I mean, I have no idea what is the problem, and if this will fix it, but if it is does, that will be very useful as a workaround and optionally to understand the problem. Understand that the gcc developers have a passive/aggressive attitude toward stabs. I think gcc retains support, only really for AIX. But further note that gcc support for stabs..we don't really need anyway. We only need the assembler and linker to work with them. (Well, I don't...) Perhaps the assembler/linker developers have a similar attitude, and perhaps, really, the problem is in them. Can you control for gas? i.e. Can you try with old gas? Or trunk gas? Or clang's assembler? Gas is a common factor here across gcc and clang and may explain that surprise. Aside: I did find a bug in clang's assembler, that affected probably nobody but us/me, on MacOSX, when targeting older systems. That caused crashing (not debugging related). I put a workaround in our gcc fork. Specifically, it had to do with matching up imported functions and their stubs/pointers. Clang's assembler assumes they are in corresponding order, and I guess ignores their names. Gcc outputs them in hash order. So the result was the assembler producing incorrect code. I changed our gcc to sort them or something. When targeting newer MacOSX I think you don't output the stuff and the linker synthesizes them. Besides that people don't target old MacOSX, people don't often send gcc's output to clang assembler. (MacOSX only has clang asssembler, at least from Apple, ignoring Homebrew). Can you copy the .o files from the working system, then gcc/link + m3gdb on new? - Jay ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* Rodney M. Bates > *Sent:* Wednesday, May 19, 2021 10:21 PM *To:* Jay K >; m3devel >; rodney.m.bates at acm.org > *Subject:* Re: [M3devel] g++9 and g++-8 undermine debugging These cases are on two machines with different linux distributions. Compiling on the old machine, with older g++/gcc(5.4.0) and with older clang++/clang (3.8.0), all cases work. On the new machine, newer g++/gcc (9.3.0) and newer clang++/clang (10.0.0), all cases fail. In all cases, with/without the ++ makes no difference. clang or gcc makes no difference. -g/-gstabs+ makes no difference. It is the same cm3 executable on both. The .o file for the one M3 module is the same size, but has different cksum. However, objdump --full-contents on them gives identical text files. Probably a compilation time/date. The compiled _m3main.o and prog vary. All other intermediate files are identical, especially _m3main.c Those cases that fail all give the same address where the debugger was unable to insert a breakpoint at: 0x9ad. Tedious debugging of m3gdb using gdb on a succeeding case had 0xa585c for the break address. This value is called a displacement in internal variables. The age of the C/C++ compiler seems to be the only variable that makes a difference. Odd that g++ and clang++ should track each other on this. On 5/18/21 7:31 PM, Jay K wrote: Can you elaborate on the matrix? gcc vs. g++ vs. clang vs. clang++ ? Do any of them work? -g vs. -gstabs vs. other forms of -g? Does anything work? "main in C" or not? Does anything work? I changed "it", I forgot, config or builder, so main is always in C, but I didn't remove the old code, so maybe try the other? Can gdb or lldb debug the C code? I realize that might not matter. I assume g++ -g/-gstabs/etc. on non-Modula3 hello world works for you? (well, some versions of -gstabs do have problems with C, but not what you describe.) - Jay ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* M3devel > on behalf of Rodney M. Bates > *Sent:* Wednesday, May 19, 2021 12:21 AM *To:* m3devel > *Subject:* [M3devel] g++9 and g++-8 undermine debugging g++9, from experimental evidence, is doing something to _m3main.o that gives m3gdb bad code addresses. m3gdb tries to insert breakpoints at invalid addresses and fails. This is for breakpoints in m3-compiled code, not in _m3main itself. g++-8 also fails. g++5 is what I have used previously, and it works. These are the only ones I have tried and can easily try. -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C8d3aca28c5fb45bf666508d91c6faa4e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637572088185808901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zPuBGdIRMAsp4wiTodVe74Uz8bQ1yWzhP6iQih9VlNE%3D&reserved=0 > >> >>> _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C8d3aca28c5fb45bf666508d91c6faa4e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637572088185818891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DDpsBQImEqoqtR0AM87AclkmaEKcQSij5x9pQfadYts%3D&reserved=0 > >> -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C8d3aca28c5fb45bf666508d91c6faa4e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637572088185818891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DDpsBQImEqoqtR0AM87AclkmaEKcQSij5x9pQfadYts%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jun 4 22:50:43 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 4 Jun 2021 20:50:43 +0000 Subject: [M3devel] more type hash collisions? Message-ID: I have not confirmed, but I think I see more type hash collisions. e.g. typedef void(__cdecl*TBAC282E7)(void); typedef TBAC282E4_fields*(__cdecl*TBAC282E7)(void) => error I imagine ProcType does not include return type in its hash. Well, that'd have way more collisions surely. It looks like these specfic types end up not used. At some point I need to remove unused types from m3c output. Or m3front could/should do it. As well, in m3c, when I call through function pointers, I cast away their type, to handle closures. So I'll just typedef these to void* or something to make progress. Perhaps it is my fault for depending on no hash collisions. Maybe we need to use type indices to backends instead. Granted that creates more work -- they'd all collide across files and force a better naming scheme. Like an actual lossless or at least almost lossless naming mechanism. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jun 6 23:30:32 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 6 Jun 2021 21:30:32 +0000 Subject: [M3devel] MachineID vs. ipv6? Message-ID: libm3: INTERFACE MachineID; TYPE T = RECORD r: ARRAY [0..5] OF BITS 8 FOR [0..255] END; PROCEDURE Get(): T; (* Returns an ID that is intended to be unique for the machine running this process until the next time this machine reboots. Thus this value is unique for this machine during the life of the calling process. Typically this value is the hardware Ethernet ID of this machine's network adaptor. On a machine without a network adaptor we return this machine's IP address which is padded with leading zero bytes. If neither is available this routine generates a checked runtime error. Consider using TimeStamp.T to generate true unique IDs, or if shorter IDs are needed and probabilistic guarantees are enough, consider using the fingerprint of a TimeStamp.T. *) Presumably we should expand this from 6 bytes, 48 bits to 16 bytes, 128 bits, to accomodate an ipv6 address? The main user seems to be TimeStamp, which I'd have to look at more. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 10 06:53:15 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 10 Jun 2021 04:53:15 +0000 Subject: [M3devel] m3main in C and cm3/pm3 detection Message-ID: Just to confirm my understanding: 1. _m3main in C does not actually break m3gdb. ? 2. The problem m3gdb was having with -g vs. -gstabs, the newer Dwarf symbols, I did fix, in m3gdb. ? 3. But there is something where m3main in C makes things hard to understand/debug, is why the change. ? 4. Depending on 2, why "Also force cm3, for now."? I really thought I fixed it. ? 5. Does m3gdb really still need to support pm3? 6. Do you test it? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvm at tut.by Thu Jun 10 09:32:03 2021 From: vvm at tut.by (vvm at tut.by) Date: Thu, 10 Jun 2021 10:32:03 +0300 Subject: [M3devel] m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: m3main in C and cm3/pm3 detection Re: g++9 and g++-8 undermine debugging In-Reply-To: References: Message-ID: <288091623309041@mail.yandex.by> An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 10 09:58:24 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 10 Jun 2021 07:58:24 +0000 Subject: [M3devel] m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: m3main in C and cm3/pm3 detection Re: g++9 and g++-8 undermine debugging In-Reply-To: <288091623309041@mail.yandex.by> References: , <288091623309041@mail.yandex.by> Message-ID: > pm3? did you test it? why not? Everything has a cost. The pm3 support has been costly because just deciding between cm3 and pm3 broke. Perhaps the better answer would be to drop support. By test, I mean, do you test with pm3. > coco/r Is this valuable? Can you bring it over to cm3? pm3 hasn't had a commit in over 10 years, or 15 years if you omit the latest 2. I realize that could mean, it is wonderful mature finished product in widespread use, no more work is needed, but it tends to imply kinda the opposite. For example it won't likely run on amd64 or arm64, which is all I use these days. - Jay ________________________________ From: vvm at tut.by Sent: Thursday, June 10, 2021 7:32 AM To: Jay K ; m3devel ; rodney_bates at lcwb.coop ; rodney.m.bates at acm.org Subject: Re: m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: [M3devel] m3main in C and cm3/pm3 detection Re: [M3devel] g++9 and g++-8 undermine debugging + rodney_bates@, rodney.m.bates@ Hi! J.K.} J.K.} 5. Does m3gdb really still need to support pm3? J.K.} Why not? pm3 contain Coco/R, for example. J.K.} J.K.} Just to confirm my understanding: J.K.} J.K.} 1. _m3main in C does not actually break m3gdb. ? J.K.} J.K.} 2. The problem m3gdb was having with -g vs. -gstabs, J.K.} the newer Dwarf symbols, I did fix, in m3gdb. ? J.K.} J.K.} 3. But there is something where m3main in C J.K.} makes things hard to understand/debug, is why the change. ? J.K.} J.K.} 4. Depending on 2, why "Also force cm3, for now."? J.K.} I really thought I fixed it. ? J.K.} It's about this ( see later)? Reinstate _m3main in m3cc, as non-default option. RodneyBates committed 10 hours ago https://github.com/modula3/cm3/commit/f51c8e22e6c0b032bbe0ac88d09a56a7c375ad63 Fix longstanding bug--missing breaks. Also force cm3, for now. Rodney M. Bates Rodney M. Bates committed 14 hours ago https://github.com/modula3/cm3/commit/f51c8e22e6c0b032bbe0ac88d09a56a7c375ad63 J.K.} J.K.} 6. Do you test it? J.K.} I will re-run tests from https://github.com/modula3/cm3/pull/634 with f51c8e2 by Rodney M. Bates J.K.} J.K.} 2. The problem m3gdb (...) J.K.} In additions of "f51c8e2 by Rodney M. Bates" we need integrated to "master" variant "A" or "B" or A+B combo: a) https://github.com/modula3/cm3/commit/0037410c6a682277c93c02b1f6cbbe53e8d47f89 {= https://github.com/modula3/cm3/commits/m3gdb === Commits on Apr 5, 2021 update m3gdb to compile on debian @demoitem demoitem committed on Apr 5 === b) https://github.com/avershov/cm3/commit/571f3a878981b00cebb8fc2eac54bc53694432c7 {= https://github.com/avershov/cm3/commits/gdb_try_fix === Commits on May 26, 2021 fixed few compilation errors on Mint20 @avershov avershov committed 13 days ago . . . === Best regards, Victor Miasnikov 10.06.2021, 07:53, "Jay K" Just to confirm my understanding: 1. _m3main in C does not actually break m3gdb. ? 2. The problem m3gdb was having with -g vs. -gstabs, the newer Dwarf symbols, I did fix, in m3gdb. ? 3. But there is something where m3main in C makes things hard to understand/debug, is why the change. ? 4. Depending on 2, why "Also force cm3, for now."? I really thought I fixed it. ? 5. Does m3gdb really still need to support pm3? 6. Do you test it? - Jay , _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvm at tut.by Thu Jun 10 10:41:00 2021 From: vvm at tut.by (vvm at tut.by) Date: Thu, 10 Jun 2021 11:41:00 +0300 Subject: [M3devel] m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: m3main in C and cm3/pm3 detection Re: g++9 and g++-8 undermine debugging In-Reply-To: References: , <288091623309041@mail.yandex.by> Message-ID: <2997221623312852@mail.yandex.by> An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 10 17:58:14 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 10 Jun 2021 15:58:14 +0000 Subject: [M3devel] single .cpp-based multi-platform release Message-ID: I made a new kind of release, that I have been working toward a while. https://github.com/modula3/cm3/releases/tag/unix64le-d5.11.1-20210610 is one .cpp file, that should work across all 64bit little endian Unix targets. (Mac, Linux, Solaris, amd64, arm64, riscv64, alpha, mips64el, powerpc64el etc.) The prerequisite then being "only" a C++ toolset, not a Modula-3 toolset. Please let me know how it goes. This can be adapted easily to build an m3cc-based system as well, from the same single file bootstrap. I'd be interested if systems run out of memory or such compiling it. In which case, maybe go back to a multi-file or few-file solution. 32bit, big endian, Windows can be supported but will require a bit more work and/or a separate file. There is still a lot that could be improved: The directions should be clearer on prerequisites, like apt-get install build-essential etc. Python2 should be updated to Python3, or use Modula-3's quake, etc. The C++ bootstrap could build m3core and libm3, providing a more complete system. It could be extended to be the entire system. The self build could be optional (i.e. if m3core/libm3 split out in the bootstrap). Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvm at tut.by Thu Jun 10 18:40:05 2021 From: vvm at tut.by (vvm at tut.by) Date: Thu, 10 Jun 2021 19:40:05 +0300 Subject: [M3devel] single .cpp-based multi-platform release In-Reply-To: References: Message-ID: <2973911623342798@mail.yandex.by> An HTML attachment was scrubbed... URL: From vvm at tut.by Thu Jun 10 18:43:50 2021 From: vvm at tut.by (vvm at tut.by) Date: Thu, 10 Jun 2021 19:43:50 +0300 Subject: [M3devel] m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: m3main in C and cm3/pm3 detection Re: g++9 and g++-8 undermine debugging In-Reply-To: <2997221623312852@mail.yandex.by> References: , <288091623309041@mail.yandex.by> <2997221623312852@mail.yandex.by> Message-ID: <2399151623343278@mail.yandex.by> An HTML attachment was scrubbed... URL: From vvm at tut.by Thu Jun 10 18:51:35 2021 From: vvm at tut.by (vvm at tut.by) Date: Thu, 10 Jun 2021 19:51:35 +0300 Subject: [M3devel] single .cpp-based multi-platform release In-Reply-To: <2973911623342798@mail.yandex.by> References: <2973911623342798@mail.yandex.by> Message-ID: <2628251623343766@mail.yandex.by> An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 10 19:57:11 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 10 Jun 2021 17:57:11 +0000 Subject: [M3devel] single .cpp-based multi-platform release In-Reply-To: <2628251623343766@mail.yandex.by> References: <2973911623342798@mail.yandex.by>,<2628251623343766@mail.yandex.by> Message-ID: > I was specifically skip step for switching to "C backend". Please clarify? You mean, either you got it working, or you would like me to document how, to make it bootstrap to an m3cc-based setup? I think, I but I didn't try it yet, just remove the "rm -rm m3-sys/{m3cc,m3gdb}" in the "middle" and the two "c" near the end. That might just work. - Jay ________________________________ From: vvm at tut.by Sent: Thursday, June 10, 2021 4:51 PM To: Jay K ; m3devel Subject: Re: [M3devel] single .cpp-based multi-platform release Hi! But: I was specifically skip step for switching to "C backend". Best regards, Victor Miasnikov 10.06.2021, 19:40, "vvm at tut.by" : Hi! > Please let me know how it goes It's have been successfully compiled to 'cm3' on Debian 8.11.1 x64. After that I run boot2min.py. All Ok. Sucefully compiled m3pp, m3gdb. ( others don't tested yet) Best regards, Victor Miasnikov 10.06.2021, 18:58, "Jay K" >: I made a new kind of release, that I have been working toward a while. https://github.com/modula3/cm3/releases/tag/unix64le-d5.11.1-20210610 is one .cpp file, that should work across all 64bit little endian Unix targets. (Mac, Linux, Solaris, amd64, arm64, riscv64, alpha, mips64el, powerpc64el etc.) The prerequisite then being "only" a C++ toolset, not a Modula-3 toolset. Please let me know how it goes. This can be adapted easily to build an m3cc-based system as well, from the same single file bootstrap. I'd be interested if systems run out of memory or such compiling it. In which case, maybe go back to a multi-file or few-file solution. 32bit, big endian, Windows can be supported but will require a bit more work and/or a separate file. There is still a lot that could be improved: The directions should be clearer on prerequisites, like apt-get install build-essential etc. Python2 should be updated to Python3, or use Modula-3's quake, etc. The C++ bootstrap could build m3core and libm3, providing a more complete system. It could be extended to be the entire system. The self build could be optional (i.e. if m3core/libm3 split out in the bootstrap). Thank you, - Jay , _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Jun 10 23:07:20 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 10 Jun 2021 16:07:20 -0500 Subject: [M3devel] m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: m3main in C and cm3/pm3 detection Re: g++9 and g++-8 undermine debugging In-Reply-To: References: <288091623309041@mail.yandex.by> Message-ID: <62f8b854-05bc-639d-d274-da2595917e08@lcwb.coop> On 6/10/21 2:58 AM, Jay K wrote: > > pm3? did you test it? why not? The issue here is not that pm3 support in m3gdb is suddenly not working. The issue is that suddenly, neither cm3 support nor pm3 support are working. But only because m3gdb can't tell which it is expected to do. All of whatever support it provides for both languages is still there. There is no reason to think this problem would lead to any loss in how m3gdb supports pm3, if only it were asked to. > > Everything has a cost. > The pm3 support has been costly because just deciding between cm3 and pm3 broke. > Perhaps the better answer would be to drop support. So do you consider the ability to get one bit of information from the compiler to the debugger so costly, that you propose instead, to drop all of pm3 debug support? I had a relative, two generations older than I, who, it was said, traded in his car whenever the ashtrays got full. "For want of a nail...". I have used m3gdb regularly, for years. It could use a *lot* of improvement, but it is hard for me to get to that, in part because I have, over and over again, had to interrupt whatever else I was doing, in order just to fix new breakages of things in m3gdb that had already been working. So it heaps insult on top of injury to hear a proposal, every time this happens, to just trash the whole thing. Well, OK, perhaps I should be glad this time, that it's a proposal to trash only part of its function. > > By test, I mean, do you test with pm3. > > > coco/r > > Is this valuable? Can you bring it over to cm3? > > pm3 hasn't had a commit in over 10 years, or 15 years if you omit the latest 2. > I realize that could mean, it is wonderful mature finished product in widespread use, no more work is needed, but it tends to imply kinda the opposite. > For example it won't likely run on amd64 or arm64, which is all I use these days. If you are only interested in supporting what you use yourself, maybe you should just fork the whole thing > > ?- Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* vvm at tut.by > *Sent:* Thursday, June 10, 2021 7:32 AM > *To:* Jay K ; m3devel ; rodney_bates at lcwb.coop ; rodney.m.bates at acm.org > *Subject:* Re: m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: [M3devel] m3main in C and cm3/pm3 detection Re: [M3devel] g++9 and g++-8 undermine debugging > + rodney_bates@, rodney.m.bates@ > Hi! > J.K.} > J.K.} 5. Does m3gdb really still need to support pm3? > J.K.} > ?Why not? > pm3 contain Coco/R, for example. > J.K.} > J.K.} Just to confirm my understanding: > J.K.} > J.K.} 1. _m3main in C does not actually break m3gdb. ? > J.K.} > J.K.} 2. The problem m3gdb was having with -g vs. -gstabs, > J.K.} ??the newer Dwarf symbols, I did fix, in m3gdb. ? > J.K.} > J.K.} 3. But there is something where m3main in C > J.K.} ???makes things hard to understand/debug, is why the change. ? > J.K.} > J.K.} 4. Depending on 2, why "Also force cm3, for now."? > J.K.} ???I really thought I fixed it. ? > J.K.} > ?It's about this ( see later)? > Reinstate _m3main in m3cc, as non-default option. > RodneyBates committed 10 hours ago > https://github.com/modula3/cm3/commit/f51c8e22e6c0b032bbe0ac88d09a56a7c375ad63 > Fix longstanding bug--missing breaks. Also force cm3, for now. > Rodney M. Bates > Rodney M. Bates committed 14 hours ago > https://github.com/modula3/cm3/commit/f51c8e22e6c0b032bbe0ac88d09a56a7c375ad63 > J.K.} > J.K.} 6. Do you test it? > J.K.} > ?I will re-run tests from > https://github.com/modula3/cm3/pull/634 > with f51c8e2 by Rodney M. Bates > J.K.} > J.K.} 2. The problem m3gdb (...) > J.K.} > ?In additions of "f51c8e2 by Rodney M. Bates" we need integrated to "master" variant "A" or "B" or A+B combo: > ?a) > https://github.com/modula3/cm3/commit/0037410c6a682277c93c02b1f6cbbe53e8d47f89 > ?{= > https://github.com/modula3/cm3/commits/m3gdb > === > Commits on Apr 5, 2021 > ? ? update m3gdb to compile on debian > ? ? @demoitem > ? ? demoitem committed on Apr 5 > === > ?b) > https://github.com/avershov/cm3/commit/571f3a878981b00cebb8fc2eac54bc53694432c7 > ?{= > https://github.com/avershov/cm3/commits/gdb_try_fix > === > Commits on May 26, 2021 > ? ? fixed few compilation errors on Mint20 > ? ? @avershov > ? ? avershov committed 13 days ago > ? . . . > === > Best regards, Victor Miasnikov > 10.06.2021, 07:53, "Jay K" > > Just to confirm my understanding: > 1. _m3main in C does not actually break m3gdb. ? > 2. The problem m3gdb was having with -g vs. -gstabs, > ? the newer Dwarf symbols, I did fix, in m3gdb. ? > 3. But there is something where m3main in C > ? ?makes things hard to understand/debug, is why the change. ? > 4. Depending on 2, why "Also force cm3, for now."? > ? ?I really thought I fixed it. ? > 5. Does m3gdb really still need to support pm3? > 6. Do you test it? > ?- Jay > , > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Thu Jun 10 23:43:34 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 10 Jun 2021 21:43:34 +0000 Subject: [M3devel] m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: m3main in C and cm3/pm3 detection Re: g++9 and g++-8 undermine debugging In-Reply-To: <62f8b854-05bc-639d-d274-da2595917e08@lcwb.coop> References: <288091623309041@mail.yandex.by> , <62f8b854-05bc-639d-d274-da2595917e08@lcwb.coop> Message-ID: M3gdb has a few problems. Git is much? slower for large repos. The vast bulk of cm3 is: M3cc M3gdb Generated docs They each have value but are very costly. Merely by sitting in git. Forking very old code is also not great. But alternatives aren?t great either: separate repos and/or submodules. Debugging is very worthwhile but maintaining a very old fork of gdb doesn?t seem like a great approach. M3c does need improvement, granted. I have already put a lot of work into that, but more is needed. Pm3 I am guessing has zero users, esp. that use current m3gdb. And a command line switch could be added for them if needed. And I did go and install old Linux and debug and I thought fix the detection in m3gdb. Did https://github.com/modula3/cm3/commit/7cb2fa6127a8929265b17c6d7e6302830a93d30d#diff-fd92157d1d31122a1aa3e0b2936baba7df98605747525cdca8114b2a78bee672 not fix it? - Jay ________________________________ From: Rodney M. Bates Sent: Thursday, June 10, 2021 2:07 PM To: Jay K; vvm at tut.by; m3devel; rodney.m.bates at acm.org Subject: Re: m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: [M3devel] m3main in C and cm3/pm3 detection Re: [M3devel] g++9 and g++-8 undermine debugging On 6/10/21 2:58 AM, Jay K wrote: > > pm3? did you test it? why not? The issue here is not that pm3 support in m3gdb is suddenly not working. The issue is that suddenly, neither cm3 support nor pm3 support are working. But only because m3gdb can't tell which it is expected to do. All of whatever support it provides for both languages is still there. There is no reason to think this problem would lead to any loss in how m3gdb supports pm3, if only it were asked to. > > Everything has a cost. > The pm3 support has been costly because just deciding between cm3 and pm3 broke. > Perhaps the better answer would be to drop support. So do you consider the ability to get one bit of information from the compiler to the debugger so costly, that you propose instead, to drop all of pm3 debug support? I had a relative, two generations older than I, who, it was said, traded in his car whenever the ashtrays got full. "For want of a nail...". I have used m3gdb regularly, for years. It could use a *lot* of improvement, but it is hard for me to get to that, in part because I have, over and over again, had to interrupt whatever else I was doing, in order just to fix new breakages of things in m3gdb that had already been working. So it heaps insult on top of injury to hear a proposal, every time this happens, to just trash the whole thing. Well, OK, perhaps I should be glad this time, that it's a proposal to trash only part of its function. > > By test, I mean, do you test with pm3. > > > coco/r > > Is this valuable? Can you bring it over to cm3? > > pm3 hasn't had a commit in over 10 years, or 15 years if you omit the latest 2. > I realize that could mean, it is wonderful mature finished product in widespread use, no more work is needed, but it tends to imply kinda the opposite. > For example it won't likely run on amd64 or arm64, which is all I use these days. If you are only interested in supporting what you use yourself, maybe you should just fork the whole thing > > - Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* vvm at tut.by > *Sent:* Thursday, June 10, 2021 7:32 AM > *To:* Jay K ; m3devel ; rodney_bates at lcwb.coop ; rodney.m.bates at acm.org > *Subject:* Re: m3gdb 1) "-no-pie" {= PIE debugging requires gdb 7.1 2) gcc -gdwarf-2 -gstrict-dwarf Re: [M3devel] m3main in C and cm3/pm3 detection Re: [M3devel] g++9 and g++-8 undermine debugging > + rodney_bates@, rodney.m.bates@ > Hi! > J.K.} > J.K.} 5. Does m3gdb really still need to support pm3? > J.K.} > Why not? > pm3 contain Coco/R, for example. > J.K.} > J.K.} Just to confirm my understanding: > J.K.} > J.K.} 1. _m3main in C does not actually break m3gdb. ? > J.K.} > J.K.} 2. The problem m3gdb was having with -g vs. -gstabs, > J.K.} the newer Dwarf symbols, I did fix, in m3gdb. ? > J.K.} > J.K.} 3. But there is something where m3main in C > J.K.} makes things hard to understand/debug, is why the change. ? > J.K.} > J.K.} 4. Depending on 2, why "Also force cm3, for now."? > J.K.} I really thought I fixed it. ? > J.K.} > It's about this ( see later)? > Reinstate _m3main in m3cc, as non-default option. > RodneyBates committed 10 hours ago > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fcommit%2Ff51c8e22e6c0b032bbe0ac88d09a56a7c375ad63&data=04%7C01%7C%7C6f422b6267054b87609f08d92c53c7df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637589560613300045%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wVOt7hUMbClh%2B3H7L4OcsGbVGRp%2Fysb1Z1By2HnQWBs%3D&reserved=0 > Fix longstanding bug--missing breaks. Also force cm3, for now. > Rodney M. Bates > Rodney M. Bates committed 14 hours ago > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fcommit%2Ff51c8e22e6c0b032bbe0ac88d09a56a7c375ad63&data=04%7C01%7C%7C6f422b6267054b87609f08d92c53c7df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637589560613310043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kYBx5lqCcCJS7TwJGLeORlO4eI5KE5JXu%2BzA608WxLM%3D&reserved=0 > J.K.} > J.K.} 6. Do you test it? > J.K.} > I will re-run tests from > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fpull%2F634&data=04%7C01%7C%7C6f422b6267054b87609f08d92c53c7df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637589560613310043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g8qC0SdaW4RbpqtFsmCYNMEFwZfUdESA4ZtG6rDn1%2Bk%3D&reserved=0 > with f51c8e2 by Rodney M. Bates > J.K.} > J.K.} 2. The problem m3gdb (...) > J.K.} > In additions of "f51c8e2 by Rodney M. Bates" we need integrated to "master" variant "A" or "B" or A+B combo: > a) > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fcommit%2F0037410c6a682277c93c02b1f6cbbe53e8d47f89&data=04%7C01%7C%7C6f422b6267054b87609f08d92c53c7df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637589560613310043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Vpypi4TPaaKIELu86p4ayrrxvN83cUdqk21nkL6nsHA%3D&reserved=0 > {= > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fcommits%2Fm3gdb&data=04%7C01%7C%7C6f422b6267054b87609f08d92c53c7df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637589560613310043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ks1aPUnewIw0wHaWdWurd5KLEo6mBixq9AP%2F1Yn6T%2F4%3D&reserved=0 > === > Commits on Apr 5, 2021 > update m3gdb to compile on debian > @demoitem > demoitem committed on Apr 5 > === > b) > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Favershov%2Fcm3%2Fcommit%2F571f3a878981b00cebb8fc2eac54bc53694432c7&data=04%7C01%7C%7C6f422b6267054b87609f08d92c53c7df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637589560613310043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7QnQJs%2BfDEtDSjdippcaETy3eKWoSFwEgc6Dy8SjSAw%3D&reserved=0 > {= > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Favershov%2Fcm3%2Fcommits%2Fgdb_try_fix&data=04%7C01%7C%7C6f422b6267054b87609f08d92c53c7df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637589560613310043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oOubZqrfHmwKYcUFPAwFewgJ5abTRPLgkqqz%2B2T1mLs%3D&reserved=0 > === > Commits on May 26, 2021 > fixed few compilation errors on Mint20 > @avershov > avershov committed 13 days ago > . . . > === > Best regards, Victor Miasnikov > 10.06.2021, 07:53, "Jay K" > > Just to confirm my understanding: > 1. _m3main in C does not actually break m3gdb. ? > 2. The problem m3gdb was having with -g vs. -gstabs, > the newer Dwarf symbols, I did fix, in m3gdb. ? > 3. But there is something where m3main in C > makes things hard to understand/debug, is why the change. ? > 4. Depending on 2, why "Also force cm3, for now."? > I really thought I fixed it. ? > 5. Does m3gdb really still need to support pm3? > 6. Do you test it? > - Jay > , > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C6f422b6267054b87609f08d92c53c7df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637589560613310043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U8CmmjZYv8b6MPq2rT3NI1JwHgTZ9PIIsnIPorEnn4U%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Jun 10 23:50:32 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 10 Jun 2021 16:50:32 -0500 Subject: [M3devel] m3main in C and cm3/pm3 detection In-Reply-To: References: Message-ID: <6b42b0cb-26e6-f194-997e-00a37a837d51@lcwb.coop> On 6/9/21 11:53 PM, Jay K wrote: > Just to confirm my understanding: > > 1. _m3main in C does not actually break m3gdb. ? As for ability to detect the compiler kind, as things now stand, _m3main in C breaks it. But just now, after a number of experiments, I have found that changing the compile command for _m3main.c to "g++ -gstabs+ ..." instead of "g++ -g ..." lets the debug symbols m3gdb needs to get through. I've lost count of how many times over the years -gstabs+ in various places got changed to -g, and I had to change it back to unbreak m3gdb. > > 2. The problem m3gdb was having with -g vs. -gstabs, > ? the newer Dwarf symbols, I did fix, in m3gdb. ? > Not sure what you mean. m3gdb has never, AFAIK, handled any dwarf symbols for modula-3 specific things, and it normally works entirely on stabs. I am sure existing code inherited from gdb 6.4 reads whatever dwarf subset that version of gdb knows about, but I doubt m3gdb would handle it in any useful way. In any case, I think we would probably need at least Dwarf 4 to handle Modula-3. > 3. But there is something where m3main in C > ? ?makes things hard to understand/debug, is why the change. ? > _m3main in m3cc has never suffered from blocking compiler detection. But it also has dramatically simplified diagnosing other recent breakages. There are several versions of gcc/g++ out there, and without even addressing what gcc has been doing, distribution packagers select different versions from what's available. Having effectively only one back end code generator cuts down the Cartesian product of experiments a whole lot. Some of the breakages appear to be not from gcc, but from changing versions of various libraries, perhaps, pthreads, or proc_service, or their header files. I've only scratched the surface of this yet, but here again, m3cc cuts down greatly on the variables. > 4. Depending on 2, why "Also force cm3, for now."? > ? ?I really thought I fixed it. ? Not that I have seen. But I just changed m3gdb some more to report whether/how it got the compiler kind and only default to cm3 if it can't get it another way. This helped a lot with experimentation and restores its ability to adapt to pm3. > > 5. Does m3gdb really still need to support pm3? Yes. I have all too many times had to find, exhume, reinsert, and reintegrate old code that was previously removed, to want to chop things out just because they are not actively used. Bringing up neglected but still present code to remove bitrot is a *lot* easier than trying to put it back in. It is far from clear that it's unused anyway, and telling people they have to rework stuff that is working for them can be cruel. _m3main in m3cc is the most recent example, though a fairly small one. > 6. Do you test it? > > ?- Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Fri Jun 11 00:22:04 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 10 Jun 2021 22:22:04 +0000 Subject: [M3devel] m3main in C and cm3/pm3 detection In-Reply-To: <6b42b0cb-26e6-f194-997e-00a37a837d51@lcwb.coop> References: , <6b42b0cb-26e6-f194-997e-00a37a837d51@lcwb.coop> Message-ID: I mean, didn?t this help: https://github.com/modula3/cm3/commit/7cb2fa6127a8929265b17c6d7e6302830a93d30d#diff-fd92157d1d31122a1aa3e0b2936baba7df98605747525cdca8114b2a78bee672 ? Because when you reported the -g vs. -gstabs problem, I did go and install Ubuntu 1604, reproduced the -g and -gstabs behaviors, and debugged and fixed -g. At least I really thought so. That commit was not for nothing. (Demonstrating the high cost of pm3!) -g is really preferable, if it can work for everyone. Modern gdb I believe entirely lacks stabs support and gcc developers want to remove stabs support, and I don?t love the idea of all this being considered ?configuration? and therefore edited. User-edited files are also an upgrade problem. I can understand the desire to reduce factors and prefer old code to be kept, possibly commented out. But even commented out code has a cognitive cost. Some projects are quite strict: all code must have a purpose and preferably test coverage, else find it in history. But I agree, finding stuff in history can be quite difficult. Sometimes we can gamble on the likelihood of needing the code. I wrestle with this a lot. It is difficult to assign absolutely zero present and hypothetical future value to things. But also cruft and cognitive cost do build up, having to constantly wonder the meaning of something. In the case of mainc vs. maincg, you see, I was similar to you, reducing a Cartesian product: less code to maintain and test, esp. across the larger cross product of backends, targets, etc. When just using C always, collapse the matrix, *seemed* to have no downside. You are still going to link to the static C startup code so you really have not reduced the code generators from 2 to 1, assuming that is C and not assembly, I would have to check. Plus all the C code in m3core. So not clear this buys anything, right? Their are some other nuances. Main in C++ is kinda required by language law to run static constructors. So kinda breaks things. But I doubt any system works that way these days. Likely Cfront did and possibly pre-ELF systems. ?Maincg? via m3c should work too, a nice result..though I would likely have to fix the typenames. But really I prefer one instead of two implementations to maintain and test. - Jay ________________________________ From: Rodney M. Bates Sent: Thursday, June 10, 2021 2:50:32 PM To: Jay K ; m3devel Subject: Re: [M3devel] m3main in C and cm3/pm3 detection On 6/9/21 11:53 PM, Jay K wrote: > Just to confirm my understanding: > > 1. _m3main in C does not actually break m3gdb. ? As for ability to detect the compiler kind, as things now stand, _m3main in C breaks it. But just now, after a number of experiments, I have found that changing the compile command for _m3main.c to "g++ -gstabs+ ..." instead of "g++ -g ..." lets the debug symbols m3gdb needs to get through. I've lost count of how many times over the years -gstabs+ in various places got changed to -g, and I had to change it back to unbreak m3gdb. > > 2. The problem m3gdb was having with -g vs. -gstabs, > the newer Dwarf symbols, I did fix, in m3gdb. ? > Not sure what you mean. m3gdb has never, AFAIK, handled any dwarf symbols for modula-3 specific things, and it normally works entirely on stabs. I am sure existing code inherited from gdb 6.4 reads whatever dwarf subset that version of gdb knows about, but I doubt m3gdb would handle it in any useful way. In any case, I think we would probably need at least Dwarf 4 to handle Modula-3. > 3. But there is something where m3main in C > makes things hard to understand/debug, is why the change. ? > _m3main in m3cc has never suffered from blocking compiler detection. But it also has dramatically simplified diagnosing other recent breakages. There are several versions of gcc/g++ out there, and without even addressing what gcc has been doing, distribution packagers select different versions from what's available. Having effectively only one back end code generator cuts down the Cartesian product of experiments a whole lot. Some of the breakages appear to be not from gcc, but from changing versions of various libraries, perhaps, pthreads, or proc_service, or their header files. I've only scratched the surface of this yet, but here again, m3cc cuts down greatly on the variables. > 4. Depending on 2, why "Also force cm3, for now."? > I really thought I fixed it. ? Not that I have seen. But I just changed m3gdb some more to report whether/how it got the compiler kind and only default to cm3 if it can't get it another way. This helped a lot with experimentation and restores its ability to adapt to pm3. > > 5. Does m3gdb really still need to support pm3? Yes. I have all too many times had to find, exhume, reinsert, and reintegrate old code that was previously removed, to want to chop things out just because they are not actively used. Bringing up neglected but still present code to remove bitrot is a *lot* easier than trying to put it back in. It is far from clear that it's unused anyway, and telling people they have to rework stuff that is working for them can be cruel. _m3main in m3cc is the most recent example, though a fairly small one. > 6. Do you test it? > > - Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C1fbf5616453044e8889408d92c59cde7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637589586482469388%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zRkbDZvXHp9%2Bph202pWlzZ%2BhNGEadr7%2BAD0pFE12Y8U%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvm at tut.by Fri Jun 11 17:20:56 2021 From: vvm at tut.by (vvm at tut.by) Date: Fri, 11 Jun 2021 18:20:56 +0300 Subject: [M3devel] single .cpp-based multi-platform release In-Reply-To: References: <2973911623342798@mail.yandex.by>, <2628251623343766@mail.yandex.by> Message-ID: <1802171623423717@mail.yandex.by> An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jun 11 22:42:07 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 11 Jun 2021 20:42:07 +0000 Subject: [M3devel] m3main in C and cm3/pm3 detection In-Reply-To: References: , <6b42b0cb-26e6-f194-997e-00a37a837d51@lcwb.coop>, Message-ID: > Having effectively only one back end code generator > cuts down the Cartesian product of experiments a whole lot. Sorry to repeat myself, but you are not really getting one code generator. There remains the C startup code (__libc_start_main on Linux) and various C code around the system esp. in m3core. > As for ability to detect the compiler kind, as things now stand, _m3main in C breaks it. Repeating again, as far as I know, I fixed this, on the m3gdb side. You confirmed with my m3gdb change? I can try again against master on Ubuntu 1604 where m3gdb builds. > m3gdb has never, AFAIK, handled any > dwarf symbols for modula-3 specific things, and it normally > works entirely on stabs. Agreed. I didn't mean to contradict that. > I am sure existing code inherited from > gdb 6.4 reads whatever dwarf subset that version of gdb knows about, > but I doubt m3gdb would handle it in any useful way. Right, that was the problem. The very attempts to read Dwarf symbols, even if they were to end up useless (except in C code!), caused the problems. As well as, I think, the hack that was there to skip Dwarf reading differently (which luckily you hadn't deleted but just skipped). (m3gdb: Some reading of Dwarf symbols so that g++ -g _m3main.c works. ? modula3/cm3 at 7cb2fa6 (github.com)) Aside: commit d2971a84b2bab683c4a1bc46a1b47a4319015b54 Author: Jay Michael Krell Date: Wed Jan 30 12:11:28 2013 +0000 *** empty log message *** was bad. I don't recall how/why that was done, esp. w/o a log message. I had earlier deleted but restored the code. - Jay ________________________________ From: Jay K Sent: Thursday, June 10, 2021 10:22 PM To: rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] m3main in C and cm3/pm3 detection I mean, didn?t this help: https://github.com/modula3/cm3/commit/7cb2fa6127a8929265b17c6d7e6302830a93d30d#diff-fd92157d1d31122a1aa3e0b2936baba7df98605747525cdca8114b2a78bee672 ? Because when you reported the -g vs. -gstabs problem, I did go and install Ubuntu 1604, reproduced the -g and -gstabs behaviors, and debugged and fixed -g. At least I really thought so. That commit was not for nothing. (Demonstrating the high cost of pm3!) -g is really preferable, if it can work for everyone. Modern gdb I believe entirely lacks stabs support and gcc developers want to remove stabs support, and I don?t love the idea of all this being considered ?configuration? and therefore edited. User-edited files are also an upgrade problem. I can understand the desire to reduce factors and prefer old code to be kept, possibly commented out. But even commented out code has a cognitive cost. Some projects are quite strict: all code must have a purpose and preferably test coverage, else find it in history. But I agree, finding stuff in history can be quite difficult. Sometimes we can gamble on the likelihood of needing the code. I wrestle with this a lot. It is difficult to assign absolutely zero present and hypothetical future value to things. But also cruft and cognitive cost do build up, having to constantly wonder the meaning of something. In the case of mainc vs. maincg, you see, I was similar to you, reducing a Cartesian product: less code to maintain and test, esp. across the larger cross product of backends, targets, etc. When just using C always, collapse the matrix, *seemed* to have no downside. You are still going to link to the static C startup code so you really have not reduced the code generators from 2 to 1, assuming that is C and not assembly, I would have to check. Plus all the C code in m3core. So not clear this buys anything, right? Their are some other nuances. Main in C++ is kinda required by language law to run static constructors. So kinda breaks things. But I doubt any system works that way these days. Likely Cfront did and possibly pre-ELF systems. ?Maincg? via m3c should work too, a nice result..though I would likely have to fix the typenames. But really I prefer one instead of two implementations to maintain and test. - Jay ________________________________ From: Rodney M. Bates Sent: Thursday, June 10, 2021 2:50:32 PM To: Jay K ; m3devel Subject: Re: [M3devel] m3main in C and cm3/pm3 detection On 6/9/21 11:53 PM, Jay K wrote: > Just to confirm my understanding: > > 1. _m3main in C does not actually break m3gdb. ? As for ability to detect the compiler kind, as things now stand, _m3main in C breaks it. But just now, after a number of experiments, I have found that changing the compile command for _m3main.c to "g++ -gstabs+ ..." instead of "g++ -g ..." lets the debug symbols m3gdb needs to get through. I've lost count of how many times over the years -gstabs+ in various places got changed to -g, and I had to change it back to unbreak m3gdb. > > 2. The problem m3gdb was having with -g vs. -gstabs, > the newer Dwarf symbols, I did fix, in m3gdb. ? > Not sure what you mean. m3gdb has never, AFAIK, handled any dwarf symbols for modula-3 specific things, and it normally works entirely on stabs. I am sure existing code inherited from gdb 6.4 reads whatever dwarf subset that version of gdb knows about, but I doubt m3gdb would handle it in any useful way. In any case, I think we would probably need at least Dwarf 4 to handle Modula-3. > 3. But there is something where m3main in C > makes things hard to understand/debug, is why the change. ? > _m3main in m3cc has never suffered from blocking compiler detection. But it also has dramatically simplified diagnosing other recent breakages. There are several versions of gcc/g++ out there, and without even addressing what gcc has been doing, distribution packagers select different versions from what's available. Having effectively only one back end code generator cuts down the Cartesian product of experiments a whole lot. Some of the breakages appear to be not from gcc, but from changing versions of various libraries, perhaps, pthreads, or proc_service, or their header files. I've only scratched the surface of this yet, but here again, m3cc cuts down greatly on the variables. > 4. Depending on 2, why "Also force cm3, for now."? > I really thought I fixed it. ? Not that I have seen. But I just changed m3gdb some more to report whether/how it got the compiler kind and only default to cm3 if it can't get it another way. This helped a lot with experimentation and restores its ability to adapt to pm3. > > 5. Does m3gdb really still need to support pm3? Yes. I have all too many times had to find, exhume, reinsert, and reintegrate old code that was previously removed, to want to chop things out just because they are not actively used. Bringing up neglected but still present code to remove bitrot is a *lot* easier than trying to put it back in. It is far from clear that it's unused anyway, and telling people they have to rework stuff that is working for them can be cruel. _m3main in m3cc is the most recent example, though a fairly small one. > 6. Do you test it? > > - Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C1fbf5616453044e8889408d92c59cde7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637589586482469388%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zRkbDZvXHp9%2Bph202pWlzZ%2BhNGEadr7%2BAD0pFE12Y8U%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jun 13 09:28:32 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 13 Jun 2021 07:28:32 +0000 Subject: [M3devel] type hashes and a possible replacement in backend interface Message-ID: C:\s\cm3\m3-sys\m3front\src\types\ProcType.m3(233): hash := Word.Plus (Word.Times (hash, 23), M3ID.Hash (formal.name)); Should parameter names really be considered as part of the type of function pointers? Or just the sequence of types? (including the return type, which is omitted presently) C:\s\cm3\m3-sys\m3front\src\types\RecordType.m3(160): hash := Word.Plus (Word.Times (hash, 41), M3ID.Hash (field.name)); Should field names really be considerd as part of the type of records? Or just the sequence of types? More so, I think backends should recieve an m3front Type along with any typeid. They could then, for example, construct long strings that "describe" the types. Something like C++ mangled names, but encoding full structure, i.e as I indicate, a sequence of field types for records (and the names if that is really required). Type should also reserve, like, backend_data: REFANY for backends to store in Type. I mean, without commenting on runtime and pickle matters, I don't think typeids actually have to be part of the backend interface. Other than as maybe a sort of convenience for backends that need hashtables and want a handy precomputed hash code, while still having a away to compare for "full" equality in the event of a collision. As well, the address of the Type could even serve as a hashcode. This would not however suffice for what m3c does with the hashes presently, as m3c works under the false assumption of no hash collisions. Which is why I want to pass in "full type info" instead. Or rather, I think full type info is already there (record fields, function pointer signatures, etc.), but the typeids also form a "primary key" running through the implied IR, i.e. connecting record types to local variables, etc. I think this needs to be fixed. I understand that pointers to m3front/Type are a problem for persistant IR like m3cc uses, but that is its problem, and..is not hard to solve. Another proposal here, keeping in mind m3cc, is for m3front to just use a hash table itself of types (handling collision via full compare) and when a new type comes along, just increment an integer. These incrementing integers could be passed to the backends. I'd call them a "typeindex" perhaps. This might even work asis, with the current backends. It would break my concatenate scenario, but I could construct what I mention above from what I have, I think. Well, they would also break likely break m3cc debuginfo. But no big deal, we could continue to pass the hashes as well, and muddle along in some places continuing to believe they do not collide. Thoughts? I am not even super keen on a solution of merely strengthening hash functions. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Sun Jun 13 20:12:27 2021 From: jayk123 at hotmail.com (Jay K) Date: Sun, 13 Jun 2021 18:12:27 +0000 Subject: [M3devel] still packing problems? Message-ID: cd scripts/python ./boot1.py i386_linux c keep "..\src\M3CG_MultiPass.m3", line 1237: CM3 restriction: non-byte-aligned value cannot be passed READONLY by reference (2.3.2) (f) "..\src\M3CG_MultiPass.m3", line 1251: CM3 restriction: non-byte-aligned value cannot be passed READONLY by reference (2.3.2) (f) 2 errors encountered I think this is here (I don't always trust line numbers, but it also gives parameter name, it'd be nice if it quoted the line and/or type): PROCEDURE replay_init_float(self: init_float_t; <*UNUSED*>replay: Replay_t; cg: cg_t) = BEGIN cg.init_float(self.byte_offset, self.float); END replay_init_float; PROCEDURE replay_load_float(self: load_float_t; <*UNUSED*>replay: Replay_t; cg: cg_t) = BEGIN cg.load_float(self.type, self.float); END replay_load_float; TYPE init_float_t = op_t OBJECT byte_offset: ByteOffset; float: Target.Float; OVERRIDES replay := replay_init_float END; TYPE load_float_t = op_t OBJECT type: RType; float: Target.Float; OVERRIDES replay := replay_load_float END; I'm pretty sure this used to work. I don't see "bits for" so m3front should add padding to make everything nicely aligned and work. init_float (o: ByteOffset; READONLY f: Target.Float); load_float (t: RType; READONLY f: Target.Float); (*push; s0.t := f *) ByteOffset = INTEGER; (* byte offset of a field *) Precision = { Short, Long, Extended }; Float = (*OPAQUE*) RECORD pre : Precision; exponent : INTEGER; fraction : EXTENDED; END; I can remove READONLY but I think it should work. It does not repro without C, presumably because I did: Target.m3: ELSIF backend_mode # M3BackendMode_t.C THEN (* Change only alignment. Size is always 64: * Aligning these types to 32 is incorrect on many but not all 32bit targets. * C backend cannot portably reduce alignment but it can portably increase * alignment. These types were 64-aligned for a very long time on * all 32bit targets. *) Longint.align := 32; Long.align := 32; Longreal.align := 32; Extended.align := 32; END; If you do change that to just ELSE then probably: ./do-pkg.py m3cc -DM3CC_TARGET=I386_LINUX build and then omit "c": ./boot1.py i386_linux keep And really, again, it should be plain ELSE. It was like that for a very long time and is correct on many platforms that way, and overaligning offsets within structs is ok. Again, it need not not actually imply alignment of locals. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Jun 14 17:17:37 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 14 Jun 2021 10:17:37 -0500 Subject: [M3devel] still packing problems? In-Reply-To: References: Message-ID: <4c071461-7c1a-c676-a11a-0a41eceef994@lcwb.coop> All of m3middle compiles for me without errors. This is on AMD64_LINUX, but the target likely would not make any difference to this. This is a very recent cm3. What cm3 are you using? On 6/13/21 1:12 PM, Jay K wrote: > cd scripts/python > ./boot1.py i386_linux c keep > > "..\src\M3CG_MultiPass.m3", line 1237: CM3 restriction: non-byte-aligned value cannot be passed READONLY by reference (2.3.2) (f) > "..\src\M3CG_MultiPass.m3", line 1251: CM3 restriction: non-byte-aligned value cannot be passed READONLY by reference (2.3.2) (f) > 2 errors encountered > > I think this is here (I don't always trust line numbers, but it also gives parameter name, it'd be nice if it quoted the line and/or type): > > PROCEDURE replay_init_float(self: init_float_t; <*UNUSED*>replay: Replay_t; cg: cg_t) = BEGIN cg.init_float(self.byte_offset, self.float); END replay_init_float; > > PROCEDURE replay_load_float(self: load_float_t; <*UNUSED*>replay: Replay_t; cg: cg_t) = BEGIN cg.load_float(self.type, self.float); END replay_load_float; > > TYPE init_float_t = op_t OBJECT byte_offset: ByteOffset; float: Target.Float; OVERRIDES replay := replay_init_float END; > TYPE load_float_t = op_t OBJECT type: RType; float: Target.Float; OVERRIDES replay := replay_load_float END; > > I'm pretty sure this used to work. > I don't see "bits for" so m3front should add padding to make everything nicely aligned and work. > > init_float (o: ByteOffset; ?READONLY f: Target.Float); > load_float ? (t: RType; ?READONLY f: Target.Float); (*push; s0.t := f *) > > ? ByteOffset = INTEGER; ?(* byte offset of a field *) > > ? Precision = { Short, Long, Extended }; > > ? Float = (*OPAQUE*) RECORD > ? ? pre ? ? ?: Precision; > ? ? exponent : INTEGER; > ? ? fraction : EXTENDED; > ? END; > > I can remove READONLY but I think it should work. > > It does not repro without C, presumably because I did: > > Target.m3: > ? ? ELSIF backend_mode # M3BackendMode_t.C THEN > ? ? ? (* Change only alignment. ?Size is always 64: > ? ? ? ?* Aligning these types to 32 is incorrect on many but not all 32bit targets. > ? ? ? ?* C backend cannot portably reduce alignment but it can portably increase > ? ? ? ?* alignment. These types were 64-aligned for a very long time on > ? ? ? ?* all 32bit targets. > ? ? ? ?*) > ? ? ? Longint.align := 32; > ? ? ? Long.align := 32; > ? ? ? Longreal.align := 32; > ? ? ? Extended.align := 32; > ? ? END; > > > If you do change that to just ELSE then probably: > > ./do-pkg.py m3cc -DM3CC_TARGET=I386_LINUX build > ?and then omit "c": > ./boot1.py i386_linux keep > > And really, again, it should be plain ELSE. > It was like that for a very long time and is correct on many platforms that way, and overaligning offsets within structs is ok. > Again, it need not not actually imply alignment of locals. > > ?- Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Mon Jun 14 17:24:51 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 14 Jun 2021 15:24:51 +0000 Subject: [M3devel] still packing problems? In-Reply-To: <4c071461-7c1a-c676-a11a-0a41eceef994@lcwb.coop> References: , <4c071461-7c1a-c676-a11a-0a41eceef994@lcwb.coop> Message-ID: The problem is specific to 32bit. And then, the C backend because it uses different alignment, the historical alignments, which are correct for many platforms and are more portability implementable. Please try the command line given. I believe I am running current, I rebuild frequently. - Jay ________________________________ From: Rodney M. Bates Sent: Monday, June 14, 2021 8:17:37 AM To: Jay K ; Randy Coleburn ; m3devel Subject: Re: [M3devel] still packing problems? All of m3middle compiles for me without errors. This is on AMD64_LINUX, but the target likely would not make any difference to this. This is a very recent cm3. What cm3 are you using? On 6/13/21 1:12 PM, Jay K wrote: > cd scripts/python > ./boot1.py i386_linux c keep > > "..\src\M3CG_MultiPass.m3", line 1237: CM3 restriction: non-byte-aligned value cannot be passed READONLY by reference (2.3.2) (f) > "..\src\M3CG_MultiPass.m3", line 1251: CM3 restriction: non-byte-aligned value cannot be passed READONLY by reference (2.3.2) (f) > 2 errors encountered > > I think this is here (I don't always trust line numbers, but it also gives parameter name, it'd be nice if it quoted the line and/or type): > > PROCEDURE replay_init_float(self: init_float_t; <*UNUSED*>replay: Replay_t; cg: cg_t) = BEGIN cg.init_float(self.byte_offset, self.float); END replay_init_float; > > PROCEDURE replay_load_float(self: load_float_t; <*UNUSED*>replay: Replay_t; cg: cg_t) = BEGIN cg.load_float(self.type, self.float); END replay_load_float; > > TYPE init_float_t = op_t OBJECT byte_offset: ByteOffset; float: Target.Float; OVERRIDES replay := replay_init_float END; > TYPE load_float_t = op_t OBJECT type: RType; float: Target.Float; OVERRIDES replay := replay_load_float END; > > I'm pretty sure this used to work. > I don't see "bits for" so m3front should add padding to make everything nicely aligned and work. > > init_float (o: ByteOffset; READONLY f: Target.Float); > load_float (t: RType; READONLY f: Target.Float); (*push; s0.t := f *) > > ByteOffset = INTEGER; (* byte offset of a field *) > > Precision = { Short, Long, Extended }; > > Float = (*OPAQUE*) RECORD > pre : Precision; > exponent : INTEGER; > fraction : EXTENDED; > END; > > I can remove READONLY but I think it should work. > > It does not repro without C, presumably because I did: > > Target.m3: > ELSIF backend_mode # M3BackendMode_t.C THEN > (* Change only alignment. Size is always 64: > * Aligning these types to 32 is incorrect on many but not all 32bit targets. > * C backend cannot portably reduce alignment but it can portably increase > * alignment. These types were 64-aligned for a very long time on > * all 32bit targets. > *) > Longint.align := 32; > Long.align := 32; > Longreal.align := 32; > Extended.align := 32; > END; > > > If you do change that to just ELSE then probably: > > ./do-pkg.py m3cc -DM3CC_TARGET=I386_LINUX build > and then omit "c": > ./boot1.py i386_linux keep > > And really, again, it should be plain ELSE. > It was like that for a very long time and is correct on many platforms that way, and overaligning offsets within structs is ok. > Again, it need not not actually imply alignment of locals. > > - Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C7461b6413cf9437ee91a08d92f479508%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637592806747117244%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0fTSFqCJ3JV8d00Wn4X00XybfeZkoEEgQvyPXUtYTZM%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Mon Jun 14 17:27:11 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 14 Jun 2021 15:27:11 +0000 Subject: [M3devel] still packing problems? In-Reply-To: References: , <4c071461-7c1a-c676-a11a-0a41eceef994@lcwb.coop>, Message-ID: Sorry, I sent those both too soon. The host doesn?t matter. Please try: ./boot1.py i386_linux c keep The problem is 32bit targets with C backend, which uses the historical alignments. - Jay ________________________________ From: Jay K Sent: Monday, June 14, 2021 8:24:51 AM To: rodney.m.bates at acm.org ; Randy Coleburn ; m3devel Subject: Re: [M3devel] still packing problems? The problem is specific to 32bit. And then, the C backend because it uses different alignment, the historical alignments, which are correct for many platforms and are more portability implementable. Please try the command line given. I believe I am running current, I rebuild frequently. - Jay ________________________________ From: Rodney M. Bates Sent: Monday, June 14, 2021 8:17:37 AM To: Jay K ; Randy Coleburn ; m3devel Subject: Re: [M3devel] still packing problems? All of m3middle compiles for me without errors. This is on AMD64_LINUX, but the target likely would not make any difference to this. This is a very recent cm3. What cm3 are you using? On 6/13/21 1:12 PM, Jay K wrote: > cd scripts/python > ./boot1.py i386_linux c keep > > "..\src\M3CG_MultiPass.m3", line 1237: CM3 restriction: non-byte-aligned value cannot be passed READONLY by reference (2.3.2) (f) > "..\src\M3CG_MultiPass.m3", line 1251: CM3 restriction: non-byte-aligned value cannot be passed READONLY by reference (2.3.2) (f) > 2 errors encountered > > I think this is here (I don't always trust line numbers, but it also gives parameter name, it'd be nice if it quoted the line and/or type): > > PROCEDURE replay_init_float(self: init_float_t; <*UNUSED*>replay: Replay_t; cg: cg_t) = BEGIN cg.init_float(self.byte_offset, self.float); END replay_init_float; > > PROCEDURE replay_load_float(self: load_float_t; <*UNUSED*>replay: Replay_t; cg: cg_t) = BEGIN cg.load_float(self.type, self.float); END replay_load_float; > > TYPE init_float_t = op_t OBJECT byte_offset: ByteOffset; float: Target.Float; OVERRIDES replay := replay_init_float END; > TYPE load_float_t = op_t OBJECT type: RType; float: Target.Float; OVERRIDES replay := replay_load_float END; > > I'm pretty sure this used to work. > I don't see "bits for" so m3front should add padding to make everything nicely aligned and work. > > init_float (o: ByteOffset; READONLY f: Target.Float); > load_float (t: RType; READONLY f: Target.Float); (*push; s0.t := f *) > > ByteOffset = INTEGER; (* byte offset of a field *) > > Precision = { Short, Long, Extended }; > > Float = (*OPAQUE*) RECORD > pre : Precision; > exponent : INTEGER; > fraction : EXTENDED; > END; > > I can remove READONLY but I think it should work. > > It does not repro without C, presumably because I did: > > Target.m3: > ELSIF backend_mode # M3BackendMode_t.C THEN > (* Change only alignment. Size is always 64: > * Aligning these types to 32 is incorrect on many but not all 32bit targets. > * C backend cannot portably reduce alignment but it can portably increase > * alignment. These types were 64-aligned for a very long time on > * all 32bit targets. > *) > Longint.align := 32; > Long.align := 32; > Longreal.align := 32; > Extended.align := 32; > END; > > > If you do change that to just ELSE then probably: > > ./do-pkg.py m3cc -DM3CC_TARGET=I386_LINUX build > and then omit "c": > ./boot1.py i386_linux keep > > And really, again, it should be plain ELSE. > It was like that for a very long time and is correct on many platforms that way, and overaligning offsets within structs is ok. > Again, it need not not actually imply alignment of locals. > > - Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C7461b6413cf9437ee91a08d92f479508%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637592806747117244%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0fTSFqCJ3JV8d00Wn4X00XybfeZkoEEgQvyPXUtYTZM%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Jun 14 17:35:09 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 14 Jun 2021 10:35:09 -0500 Subject: [M3devel] type hashes and a possible replacement in backend interface In-Reply-To: References: Message-ID: <9f026e4d-a636-9b7c-d6e7-775dd6a7adb7@lcwb.coop> This hash computation has multiple problems: 1) Formal names are not part of a procedure type and should not be included in the hash. 2) Their types are, but are not being included. 3) As you note the result type is also omitted, but should be included. I didn't track down where this hash is used, but it is surprising it hasn't caused noticeable trouble before. If used in a hash table, 1) would cause equal types to be mistakenly considered unequal. 2) and 3) would cause, at best, poor hash table performance. 2) by itself should cause far more collision than you have seen, but I suppose 1) may be compensating, sort of. I didn't look at the fingerprint, thus derived UID. They might be better. On 6/13/21 2:28 AM, Jay K wrote: > C:\s\cm3\m3-sys\m3front\src\types\ProcType.m3(233): ? ? ?hash := Word.Plus (Word.Times (hash, 23), M3ID.Hash (formal.name)); > > > Should parameter names really be considered as part of the type of function pointers? > Or just the sequence of types? > (including the return type, which is omitted presently) > > > C:\s\cm3\m3-sys\m3front\src\types\RecordType.m3(160): ? ? ?hash := Word.Plus (Word.Times (hash, 41), M3ID.Hash (field.name)); > > > Should field names really be considerd as part of the type of records? > Or just the sequence of types? > > > More so, I think backends should recieve an m3front Type along with any typeid. > They could then, for example, construct long strings that "describe" the types. > ? Something like C++ mangled names, but encoding full structure, i.e as I indicate, > ? a sequence of field types for records (and the names if that is really required). > > Type should also reserve, like, backend_data: REFANY for backends to store in Type. > > ?I mean, without commenting on runtime and pickle matters, I don't think typeids > actually have to be part of the backend interface. Other than as maybe a sort of > convenience for backends that need hashtables and want a handy precomputed hash > code, while still having a away to compare for "full" equality in the event of a collision. > > As well, the address of the Type could even serve as a hashcode. > This would not however suffice for what m3c does with the hashes presently, > as m3c works under the false assumption of no hash collisions. > > Which is why I want to pass in "full type info" instead. > > Or rather, I think full type info is already there (record fields, function pointer > signatures, etc.), but the typeids also form a "primary key" running through > the implied IR, i.e. connecting record types to local variables, etc. > I think this needs to be fixed. > > I understand that pointers to m3front/Type are a problem for persistant > IR like m3cc uses, but that is its problem, and..is not hard to solve. > > Another proposal here, keeping in mind m3cc, is for m3front > to just use a hash table itself of types (handling collision via full compare) and when a new > type comes along, just increment an integer. > These incrementing integers could be passed to the backends. > I'd call them a "typeindex" perhaps. > This might even work asis, with the current backends. > It would break my concatenate scenario, but I could construct > what I mention above from what I have, I think. > Well, they would also break likely break m3cc debuginfo. > But no big deal, we could continue to pass the hashes as well, and muddle along in some places continuing to believe they do not collide. > > Thoughts? > > I am not even super keen on a solution of merely strengthening hash functions. > > ? - Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Mon Jun 14 17:54:13 2021 From: jayk123 at hotmail.com (Jay K) Date: Mon, 14 Jun 2021 15:54:13 +0000 Subject: [M3devel] type hashes and a possible replacement in backend interface In-Reply-To: <9f026e4d-a636-9b7c-d6e7-775dd6a7adb7@lcwb.coop> References: , <9f026e4d-a636-9b7c-d6e7-775dd6a7adb7@lcwb.coop> Message-ID: Right, I guess the parameter names mitigate. I do see collisions. I generally use type hashes as identifiers that are types. However I do not use them for procedure types due to the high collision rate. Also low value, not really useful in a debugger. I also append an enum?s size to its name as they have collisions too. - Jay ________________________________ From: Rodney M. Bates Sent: Monday, June 14, 2021 8:35:09 AM To: Jay K ; m3devel Subject: Re: [M3devel] type hashes and a possible replacement in backend interface This hash computation has multiple problems: 1) Formal names are not part of a procedure type and should not be included in the hash. 2) Their types are, but are not being included. 3) As you note the result type is also omitted, but should be included. I didn't track down where this hash is used, but it is surprising it hasn't caused noticeable trouble before. If used in a hash table, 1) would cause equal types to be mistakenly considered unequal. 2) and 3) would cause, at best, poor hash table performance. 2) by itself should cause far more collision than you have seen, but I suppose 1) may be compensating, sort of. I didn't look at the fingerprint, thus derived UID. They might be better. On 6/13/21 2:28 AM, Jay K wrote: > C:\s\cm3\m3-sys\m3front\src\types\ProcType.m3(233): hash := Word.Plus (Word.Times (hash, 23), M3ID.Hash (formal.name)); > > > Should parameter names really be considered as part of the type of function pointers? > Or just the sequence of types? > (including the return type, which is omitted presently) > > > C:\s\cm3\m3-sys\m3front\src\types\RecordType.m3(160): hash := Word.Plus (Word.Times (hash, 41), M3ID.Hash (field.name)); > > > Should field names really be considerd as part of the type of records? > Or just the sequence of types? > > > More so, I think backends should recieve an m3front Type along with any typeid. > They could then, for example, construct long strings that "describe" the types. > Something like C++ mangled names, but encoding full structure, i.e as I indicate, > a sequence of field types for records (and the names if that is really required). > > Type should also reserve, like, backend_data: REFANY for backends to store in Type. > > I mean, without commenting on runtime and pickle matters, I don't think typeids > actually have to be part of the backend interface. Other than as maybe a sort of > convenience for backends that need hashtables and want a handy precomputed hash > code, while still having a away to compare for "full" equality in the event of a collision. > > As well, the address of the Type could even serve as a hashcode. > This would not however suffice for what m3c does with the hashes presently, > as m3c works under the false assumption of no hash collisions. > > Which is why I want to pass in "full type info" instead. > > Or rather, I think full type info is already there (record fields, function pointer > signatures, etc.), but the typeids also form a "primary key" running through > the implied IR, i.e. connecting record types to local variables, etc. > I think this needs to be fixed. > > I understand that pointers to m3front/Type are a problem for persistant > IR like m3cc uses, but that is its problem, and..is not hard to solve. > > Another proposal here, keeping in mind m3cc, is for m3front > to just use a hash table itself of types (handling collision via full compare) and when a new > type comes along, just increment an integer. > These incrementing integers could be passed to the backends. > I'd call them a "typeindex" perhaps. > This might even work asis, with the current backends. > It would break my concatenate scenario, but I could construct > what I mention above from what I have, I think. > Well, they would also break likely break m3cc debuginfo. > But no big deal, we could continue to pass the hashes as well, and muddle along in some places continuing to believe they do not collide. > > Thoughts? > > I am not even super keen on a solution of merely strengthening hash functions. > > - Jay > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Cd2e166feff1948ebe49408d92f4a058b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637592817224723581%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=je45cCzleSv5iptCt4iMDhq%2F2EnN%2FToCy6mc%2BiBimFk%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.mckinna at gmail.com Wed Jun 16 12:24:06 2021 From: peter.mckinna at gmail.com (Peter McKinna) Date: Wed, 16 Jun 2021 20:24:06 +1000 Subject: [M3devel] odd declare_local in IR Message-ID: Has anyone seen anything like this? declare_local Heap temp ptr, line 538 8 8 Addr 1035065828 T F 50 v.238 There are a few of them in Dynamic.mc in test p269 That Heap temp ptr looks suspicious. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Jun 16 21:08:35 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Jun 2021 14:08:35 -0500 Subject: [M3devel] odd declare_local in IR In-Reply-To: References: Message-ID: <68e644f2-2455-eece-bbec-884aabb62e69@lcwb.coop> It's intentional, two reasons. From ArrayExpr.m3:1616: (* There must exist a variable of type top.refType, to get its typecell emitted. Also, we gen code to store address of heap-allocated temp therein, so GC will leave it alone. *) name := M3ID.Add ("Heap temp ptr, line " & Fmt.Int (top.origin MOD 100000)); top.heapTempPtrVar := CG.Declare_local (name, Target.Address.size, Target.Address.align, CG.Type.Addr, Type.GlobalUID (top.refType), in_memory := TRUE, up_level := FALSE, f := CG.Maybe); CG.Push (top.buildAddrVal); CG.Boost_addr_alignment (Target.Address.align); CG.Store_addr (top.heapTempPtrVar, (*Offset:=*) 0); And 2212: IF top.finalVal = NIL THEN CG.Push (top.buildAddrVal) (* Return the temp. *) (* CHECK: Leave top.heapTempPtrVar alone. If used in a WITH-binding, WithStmt will copy only the dope into a variable. This will maintain only a pointer to the elements portion of the temporary. Is a pointer to the interior of a heap object enough to protect it from GC? *) And 2235: (* Now we can NIL out the heap object pointer, to be collected. *) IF top.heapTempPtrVar # NIL THEN CG.Load_nil (); CG.Store_addr (top.heapTempPtrVar, (*Offset:=*) 0); END; I don't know if a pointer to the proper interior of a heap object will protect the object from GC, but it seems like it would have some major performance implications for the GC to ensure this. On 6/16/21 5:24 AM, Peter McKinna wrote: > Has anyone seen anything like this? > > declare_local Heap temp ptr, line 538 8 8 Addr 1035065828 T F 50 v.238 > > There are a few of them in Dynamic.mc in test p269 > > That Heap temp ptr looks suspicious. > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu Jun 17 19:03:52 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Jun 2021 12:03:52 -0500 Subject: [M3devel] Another m3gdb breakage Message-ID: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> Breakpoint 1, PrepArg (formal=16_00000000037f5e70, actExpr=16_00000000037a6b18) at ../src/values/Formal.m3:605 605 Error.ID (formVal.name, Current language: auto; currently Modula-3 (m3gdb) p formVal Can't find RT0.Typecell. Maybe M3 libraries are compiled without debug info, or not stabs. (m3gdb) p RT0.Typecell Can't find Modula-3 qualified reference: RT0.Typecell (m3gdb) p RT0__Typecell Can't find Modula-3 identifier: RT0__Typecell (m3gdb) p RTType.NULL_typecell $1 = RECORD typecode = 0; selfID = 1223456110; fp = {110, 117, 108, 108, 0, 0, 128, 36}; traced = 0; kind = 1; link_state = 1; dataAlignment = 1; dataSize = 0; type_map = NIL; gc_map = NIL; type_desc = NIL; initProc = NIL; brand_ptr = NIL; name = 16_00000000008ae080; next = NIL; END objdump -g RT0_i.o gives: ... struct MN_Eic7CJ { /* id 99 */ int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ int64 Eic7CJ; /* bitsize 64, bitpos 0 */ }; ... -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Thu Jun 17 19:14:36 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 17 Jun 2021 17:14:36 +0000 Subject: [M3devel] Another m3gdb breakage In-Reply-To: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> Message-ID: Details? Broken by:? Newer gcc? Newer ld? Newer mod? Newer gcc/ld flags? Last known working:? Recently? Long ago? Never known to work but should work? - Jay ________________________________ From: M3devel on behalf of Rodney M. Bates Sent: Thursday, June 17, 2021 10:03:52 AM To: m3devel Subject: [M3devel] Another m3gdb breakage Breakpoint 1, PrepArg (formal=16_00000000037f5e70, actExpr=16_00000000037a6b18) at ../src/values/Formal.m3:605 605 Error.ID (formVal.name, Current language: auto; currently Modula-3 (m3gdb) p formVal Can't find RT0.Typecell. Maybe M3 libraries are compiled without debug info, or not stabs. (m3gdb) p RT0.Typecell Can't find Modula-3 qualified reference: RT0.Typecell (m3gdb) p RT0__Typecell Can't find Modula-3 identifier: RT0__Typecell (m3gdb) p RTType.NULL_typecell $1 = RECORD typecode = 0; selfID = 1223456110; fp = {110, 117, 108, 108, 0, 0, 128, 36}; traced = 0; kind = 1; link_state = 1; dataAlignment = 1; dataSize = 0; type_map = NIL; gc_map = NIL; type_desc = NIL; initProc = NIL; brand_ptr = NIL; name = 16_00000000008ae080; next = NIL; END objdump -g RT0_i.o gives: ... struct MN_Eic7CJ { /* id 99 */ int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ int64 Eic7CJ; /* bitsize 64, bitpos 0 */ }; ... -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C87acb39112dd4c192afb08d931b1f17c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595462591608939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IezAWSkOY7Nni5cvbINb0NdbJRwFHDiR3oeiZUCu%2F1c%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Thu Jun 17 19:18:37 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 17 Jun 2021 17:18:37 +0000 Subject: [M3devel] Another m3gdb breakage In-Reply-To: References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop>, Message-ID: Also what is expected? What is old output? Is it the underscores vs. the dots? Maybe my changes in m3front related to typenames? I can maybe meet my goals with less change. I mean, I maybe changed the IR a bit here and can maybe do less change or feed old data and new. - Jay ________________________________ From: M3devel on behalf of Jay K Sent: Thursday, June 17, 2021 10:14:36 AM To: rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] Another m3gdb breakage Details? Broken by:? Newer gcc? Newer ld? Newer mod? Newer gcc/ld flags? Last known working:? Recently? Long ago? Never known to work but should work? - Jay ________________________________ From: M3devel on behalf of Rodney M. Bates Sent: Thursday, June 17, 2021 10:03:52 AM To: m3devel Subject: [M3devel] Another m3gdb breakage Breakpoint 1, PrepArg (formal=16_00000000037f5e70, actExpr=16_00000000037a6b18) at ../src/values/Formal.m3:605 605 Error.ID (formVal.name, Current language: auto; currently Modula-3 (m3gdb) p formVal Can't find RT0.Typecell. Maybe M3 libraries are compiled without debug info, or not stabs. (m3gdb) p RT0.Typecell Can't find Modula-3 qualified reference: RT0.Typecell (m3gdb) p RT0__Typecell Can't find Modula-3 identifier: RT0__Typecell (m3gdb) p RTType.NULL_typecell $1 = RECORD typecode = 0; selfID = 1223456110; fp = {110, 117, 108, 108, 0, 0, 128, 36}; traced = 0; kind = 1; link_state = 1; dataAlignment = 1; dataSize = 0; type_map = NIL; gc_map = NIL; type_desc = NIL; initProc = NIL; brand_ptr = NIL; name = 16_00000000008ae080; next = NIL; END objdump -g RT0_i.o gives: ... struct MN_Eic7CJ { /* id 99 */ int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ int64 Eic7CJ; /* bitsize 64, bitpos 0 */ }; ... -- Rodney Bates rodney.m.bates at acm.org _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C87acb39112dd4c192afb08d931b1f17c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595462591608939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IezAWSkOY7Nni5cvbINb0NdbJRwFHDiR3oeiZUCu%2F1c%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Jun 17 19:29:14 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Jun 2021 12:29:14 -0500 Subject: [M3devel] Another m3gdb breakage In-Reply-To: References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> Message-ID: <12b49c12-958a-2e8c-b780-5e3aa5162d05@lcwb.coop> On 6/17/21 12:14 PM, Jay K wrote: > Details? > Broken by:? Don't know yet, but flags seem most likely > ? Newer gcc? > ? Newer ld? > ? Newer mod? > ? Newer gcc/ld flags? > > ? Last known working:? Maybe a month ago, with recent gcc and ld > ? ? Recently? > ? ? ?Long ago? > ? ? Never known to work but should work? > > - Jay > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Rodney M. Bates > *Sent:* Thursday, June 17, 2021 10:03:52 AM > *To:* m3devel > *Subject:* [M3devel] Another m3gdb breakage > Breakpoint 1, PrepArg (formal=16_00000000037f5e70, actExpr=16_00000000037a6b18) > ???? at ../src/values/Formal.m3:605 > 605???????????????? Error.ID (formVal.name, > Current language:? auto; currently Modula-3 > (m3gdb) p formVal > Can't find RT0.Typecell. Maybe M3 libraries are compiled without debug info, or not stabs. > > (m3gdb) p RT0.Typecell > Can't find Modula-3 qualified reference: RT0.Typecell > (m3gdb) p RT0__Typecell > Can't find Modula-3 identifier: RT0__Typecell > (m3gdb) p RTType.NULL_typecell > $1 = RECORD typecode = 0; selfID = 1223456110; fp = {110, 117, 108, 108, 0, 0, 128, 36}; > ???? traced = 0; kind = 1; link_state = 1; dataAlignment = 1; dataSize = 0; type_map = NIL; > ???? gc_map = NIL; type_desc = NIL; initProc = NIL; brand_ptr = NIL; > ???? name = 16_00000000008ae080; next = NIL;? END > > objdump -g RT0_i.o gives: > ... > struct MN_Eic7CJ { /* id 99 */ > ?? int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ > }; > struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ > ?? int64 Eic7CJ; /* bitsize 64, bitpos 0 */ > }; > ... > > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C87acb39112dd4c192afb08d931b1f17c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595462591608939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IezAWSkOY7Nni5cvbINb0NdbJRwFHDiR3oeiZUCu%2F1c%3D&reserved=0 > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Thu Jun 17 19:32:43 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Jun 2021 12:32:43 -0500 Subject: [M3devel] Another m3gdb breakage In-Reply-To: References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> Message-ID: <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop> On 6/17/21 12:18 PM, Jay K wrote: > Also what is expected? > What is old output? print argVal shows the fields. (argVal is an object.) print RT0.Typecell (a type) gives file name and line number of type declaration > Is it the underscores vs. the dots? These are equivalent, should give same results > Maybe my changes in m3front related to typenames? > I can maybe meet my goals with less change. > I mean, I maybe changed the IR a bit here and can maybe do less change or feed old data and new. > > - Jay > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Jay K > *Sent:* Thursday, June 17, 2021 10:14:36 AM > *To:* rodney.m.bates at acm.org ; m3devel > *Subject:* Re: [M3devel] Another m3gdb breakage > Details? > Broken by:? > ? Newer gcc? > ? Newer ld? > ? Newer mod? > ? Newer gcc/ld flags? > > ? Last known working:? > ? ? Recently? > ? ? ?Long ago? > ? ? Never known to work but should work? > > - Jay > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Rodney M. Bates > *Sent:* Thursday, June 17, 2021 10:03:52 AM > *To:* m3devel > *Subject:* [M3devel] Another m3gdb breakage > Breakpoint 1, PrepArg (formal=16_00000000037f5e70, actExpr=16_00000000037a6b18) > ???? at ../src/values/Formal.m3:605 > 605???????????????? Error.ID (formVal.name, > Current language:? auto; currently Modula-3 > (m3gdb) p formVal > Can't find RT0.Typecell. Maybe M3 libraries are compiled without debug info, or not stabs. > > (m3gdb) p RT0.Typecell > Can't find Modula-3 qualified reference: RT0.Typecell > (m3gdb) p RT0__Typecell > Can't find Modula-3 identifier: RT0__Typecell > (m3gdb) p RTType.NULL_typecell > $1 = RECORD typecode = 0; selfID = 1223456110; fp = {110, 117, 108, 108, 0, 0, 128, 36}; > ???? traced = 0; kind = 1; link_state = 1; dataAlignment = 1; dataSize = 0; type_map = NIL; > ???? gc_map = NIL; type_desc = NIL; initProc = NIL; brand_ptr = NIL; > ???? name = 16_00000000008ae080; next = NIL;? END > > objdump -g RT0_i.o gives: > ... > struct MN_Eic7CJ { /* id 99 */ > ?? int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ > }; > struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ > ?? int64 Eic7CJ; /* bitsize 64, bitpos 0 */ > }; > ... > > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7C87acb39112dd4c192afb08d931b1f17c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595462591608939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IezAWSkOY7Nni5cvbINb0NdbJRwFHDiR3oeiZUCu%2F1c%3D&reserved=0 > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Thu Jun 17 19:39:03 2021 From: jayk123 at hotmail.com (Jay K) Date: Thu, 17 Jun 2021 17:39:03 +0000 Subject: [M3devel] Another m3gdb breakage In-Reply-To: <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop> References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> , <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop> Message-ID: I have a feeling it is my changes in m3front. It almost seems backwards. I was trying to preserve typenames more and give backends more information. But in doing so I must have somehow taken information away from m3cc. Old vs. new IR for RT0_i will probably make it clearer what I broke and what m3cc/m3gdb require. Hopefully we can satisfy both m3cc and m3c. Not m3c per se -- it was already working -- but the concatenate all the files scenario. Or maybe it is gcc/ld/flags, maybe. In which case, easy enough, just a little "icky", can conditionalize them on backend mode. - Jay ________________________________ From: Rodney M. Bates Sent: Thursday, June 17, 2021 5:32 PM To: Jay K ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] Another m3gdb breakage On 6/17/21 12:18 PM, Jay K wrote: > Also what is expected? > What is old output? print argVal shows the fields. (argVal is an object.) print RT0.Typecell (a type) gives file name and line number of type declaration > Is it the underscores vs. the dots? These are equivalent, should give same results > Maybe my changes in m3front related to typenames? > I can maybe meet my goals with less change. > I mean, I maybe changed the IR a bit here and can maybe do less change or feed old data and new. > > - Jay > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Jay K > *Sent:* Thursday, June 17, 2021 10:14:36 AM > *To:* rodney.m.bates at acm.org ; m3devel > *Subject:* Re: [M3devel] Another m3gdb breakage > Details? > Broken by:? > Newer gcc? > Newer ld? > Newer mod? > Newer gcc/ld flags? > > Last known working:? > Recently? > Long ago? > Never known to work but should work? > > - Jay > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* M3devel on behalf of Rodney M. Bates > *Sent:* Thursday, June 17, 2021 10:03:52 AM > *To:* m3devel > *Subject:* [M3devel] Another m3gdb breakage > Breakpoint 1, PrepArg (formal=16_00000000037f5e70, actExpr=16_00000000037a6b18) > at ../src/values/Formal.m3:605 > 605 Error.ID (formVal.name, > Current language: auto; currently Modula-3 > (m3gdb) p formVal > Can't find RT0.Typecell. Maybe M3 libraries are compiled without debug info, or not stabs. > > (m3gdb) p RT0.Typecell > Can't find Modula-3 qualified reference: RT0.Typecell > (m3gdb) p RT0__Typecell > Can't find Modula-3 identifier: RT0__Typecell > (m3gdb) p RTType.NULL_typecell > $1 = RECORD typecode = 0; selfID = 1223456110; fp = {110, 117, 108, 108, 0, 0, 128, 36}; > traced = 0; kind = 1; link_state = 1; dataAlignment = 1; dataSize = 0; type_map = NIL; > gc_map = NIL; type_desc = NIL; initProc = NIL; brand_ptr = NIL; > name = 16_00000000008ae080; next = NIL; END > > objdump -g RT0_i.o gives: > ... > struct MN_Eic7CJ { /* id 99 */ > int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ > }; > struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ > int64 Eic7CJ; /* bitsize 64, bitpos 0 */ > }; > ... > > > -- > Rodney Bates > rodney.m.bates at acm.org > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Ce1e905e381994923efa308d931b5f1ca%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595479789370478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KPmrZKncahh2iWWJMqmCWADpP2whWiu3yBwkwysfWig%3D&reserved=0 > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Ce1e905e381994923efa308d931b5f1ca%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595479789370478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KPmrZKncahh2iWWJMqmCWADpP2whWiu3yBwkwysfWig%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Jun 18 02:15:52 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 17 Jun 2021 19:15:52 -0500 Subject: [M3devel] Another m3gdb breakage In-Reply-To: References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop> Message-ID: It's typename changes that did it. From an objdump -g of an old RT0_i.o that I was able to find: struct MN_Eic7CJ { /* id 75 */ int64 RT0.Typecell; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.Typecell { /* id 76 */ int64 Eic7CJ; /* bitsize 64, bitpos 0 */ }; struct MN_AjiXrU { /* id 77 */ int64 RT0.ObjectTypeDefn; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.ObjectTypeDefn { /* id 78 */ int64 AjiXrU; /* bitsize 64, bitpos 0 */ }; struct MN_CoL0WS { /* id 79 */ int64 RT0.ObjectTypecell; /* bitsize 64, bitpos 0 */ }; From Current: struct MN_Eic7CJ { /* id 99 */ int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ int64 Eic7CJ; /* bitsize 64, bitpos 0 */ }; struct MN_AjiXrU { /* id 101 */ int64 RT0.RT0__ObjectTypeDefn; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.RT0__ObjectTypeDefn { /* id 102 */ int64 AjiXrU; /* bitsize 64, bitpos 0 */ }; struct MN_CoL0WS { /* id 103 */ int64 RT0.RT0__ObjectTypecell; /* bitsize 64, bitpos 0 */ }; The names already had an "RT0." prefix. Now they have "RT0.RT0__ prefix". I don't know if type names from m3front end up elsewhere besides debug entries for types, but for debug info, they need to stay as they were. On 6/17/21 12:39 PM, Jay K wrote: > I have a feeling it is my changes in m3front. > It almost seems backwards. > I was trying to preserve typenames more and give backends more information. > But in doing so I must have somehow taken information away from m3cc. > Old vs. new IR for RT0_i will probably make it clearer what I broke and what m3cc/m3gdb require. > Hopefully we can satisfy both m3cc and m3c. > Not m3c per se -- it was already working -- but the concatenate all the files scenario. > > Or maybe it is gcc/ld/flags, maybe. > In which case, easy enough, just a little "icky", can conditionalize them on backend mode. > > ?- Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Rodney M. Bates > *Sent:* Thursday, June 17, 2021 5:32 PM > *To:* Jay K ; rodney.m.bates at acm.org ; m3devel > *Subject:* Re: [M3devel] Another m3gdb breakage > > > On 6/17/21 12:18 PM, Jay K wrote: >> Also what is expected? >> What is old output? > print argVal shows the fields.? (argVal is an object.) > print RT0.Typecell (a type) gives file name and line number of type declaration >> Is it the underscores vs. the dots? > These are equivalent, should give same results >> Maybe my changes in m3front related to typenames? >> I can maybe meet my goals with less change. >> I mean, I maybe changed the IR a bit here and can maybe do less change or feed old data and new. >> >> - Jay >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* M3devel on behalf of Jay K >> *Sent:* Thursday, June 17, 2021 10:14:36 AM >> *To:* rodney.m.bates at acm.org ; m3devel >> *Subject:* Re: [M3devel] Another m3gdb breakage >> Details? >> Broken by:? >>? ? Newer gcc? >>? ? Newer ld? >>? ? Newer mod? >>? ? Newer gcc/ld flags? >> >>? ? Last known working:? >>? ? ? Recently? >>? ? ? ?Long ago? >>? ? ? Never known to work but should work? >> >> - Jay >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* M3devel on behalf of Rodney M. Bates >> *Sent:* Thursday, June 17, 2021 10:03:52 AM >> *To:* m3devel >> *Subject:* [M3devel] Another m3gdb breakage >> Breakpoint 1, PrepArg (formal=16_00000000037f5e70, actExpr=16_00000000037a6b18) >>? ???? at ../src/values/Formal.m3:605 >> 605???????????????? Error.ID (formVal.name, >> Current language:? auto; currently Modula-3 >> (m3gdb) p formVal >> Can't find RT0.Typecell. Maybe M3 libraries are compiled without debug info, or not stabs. >> >> (m3gdb) p RT0.Typecell >> Can't find Modula-3 qualified reference: RT0.Typecell >> (m3gdb) p RT0__Typecell >> Can't find Modula-3 identifier: RT0__Typecell >> (m3gdb) p RTType.NULL_typecell >> $1 = RECORD typecode = 0; selfID = 1223456110; fp = {110, 117, 108, 108, 0, 0, 128, 36}; >>? ???? traced = 0; kind = 1; link_state = 1; dataAlignment = 1; dataSize = 0; type_map = NIL; >>? ???? gc_map = NIL; type_desc = NIL; initProc = NIL; brand_ptr = NIL; >>? ???? name = 16_00000000008ae080; next = NIL;? END >> >> objdump -g RT0_i.o gives: >> ... >> struct MN_Eic7CJ { /* id 99 */ >>? ?? int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ >> }; >> struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ >>? ?? int64 Eic7CJ; /* bitsize 64, bitpos 0 */ >> }; >> ... >> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Ce1e905e381994923efa308d931b5f1ca%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595479789370478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KPmrZKncahh2iWWJMqmCWADpP2whWiu3yBwkwysfWig%3D&reserved=0 > > >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Ce1e905e381994923efa308d931b5f1ca%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595479789370478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KPmrZKncahh2iWWJMqmCWADpP2whWiu3yBwkwysfWig%3D&reserved=0 >> > > -- > Rodney Bates > rodney.m.bates at acm.org > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Fri Jun 18 04:20:39 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 18 Jun 2021 02:20:39 +0000 Subject: [M3devel] Another m3gdb breakage In-Reply-To: References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop> , Message-ID: In m3c ?they? end up in the generated C. When compiling individual files, the names don?t really matter. When concatenating ?all? the files, such as that make up cm3, along with hand written m3core.h and *.c, the names need to match the hand written code. So then ?they? matter. However ?they? is ambiguous. Specifically the declare_typename calls were problematic. I?d fix them, and find more problems, repeatedly. What worked much better in the end was passing contextual typenames at each use, like in declare_param and import_global. The biggest problem from memory was discerning int and const_int. They are different at the C level (actual readonly efficiently cachacheable shareable memory) but hash the same because Modula3 has no provision for such optimization in its type system, alas. I went to some pain to make typenames fully qualified: Module__type. Previously, sometimes they were, sometimes not, depending on what the original Modula3 source looked like. I Iater noticed the comment that typenames are implicitly contextual. For example types can be names in procedures and probably blocks therein. Modules are not the only name scope. For now I am only interested in parameter and return type names. Locals? names in time might be interesting but it is way out there. I still think some notion of ?fully qualified? typename coming from m3front makes sense, alleviating possible backend duplication. Maybe both, prior contextual and new fully qualified? Perhaps m3cc is prefixing module to typenames and can stop doing that? Anyway I will try to look at it. - Jay ________________________________ From: Rodney M. Bates Sent: Thursday, June 17, 2021 5:15:52 PM To: Jay K ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] Another m3gdb breakage It's typename changes that did it. From an objdump -g of an old RT0_i.o that I was able to find: struct MN_Eic7CJ { /* id 75 */ int64 RT0.Typecell; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.Typecell { /* id 76 */ int64 Eic7CJ; /* bitsize 64, bitpos 0 */ }; struct MN_AjiXrU { /* id 77 */ int64 RT0.ObjectTypeDefn; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.ObjectTypeDefn { /* id 78 */ int64 AjiXrU; /* bitsize 64, bitpos 0 */ }; struct MN_CoL0WS { /* id 79 */ int64 RT0.ObjectTypecell; /* bitsize 64, bitpos 0 */ }; From Current: struct MN_Eic7CJ { /* id 99 */ int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ int64 Eic7CJ; /* bitsize 64, bitpos 0 */ }; struct MN_AjiXrU { /* id 101 */ int64 RT0.RT0__ObjectTypeDefn; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.RT0__ObjectTypeDefn { /* id 102 */ int64 AjiXrU; /* bitsize 64, bitpos 0 */ }; struct MN_CoL0WS { /* id 103 */ int64 RT0.RT0__ObjectTypecell; /* bitsize 64, bitpos 0 */ }; The names already had an "RT0." prefix. Now they have "RT0.RT0__ prefix". I don't know if type names from m3front end up elsewhere besides debug entries for types, but for debug info, they need to stay as they were. On 6/17/21 12:39 PM, Jay K wrote: > I have a feeling it is my changes in m3front. > It almost seems backwards. > I was trying to preserve typenames more and give backends more information. > But in doing so I must have somehow taken information away from m3cc. > Old vs. new IR for RT0_i will probably make it clearer what I broke and what m3cc/m3gdb require. > Hopefully we can satisfy both m3cc and m3c. > Not m3c per se -- it was already working -- but the concatenate all the files scenario. > > Or maybe it is gcc/ld/flags, maybe. > In which case, easy enough, just a little "icky", can conditionalize them on backend mode. > > - Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Rodney M. Bates > *Sent:* Thursday, June 17, 2021 5:32 PM > *To:* Jay K ; rodney.m.bates at acm.org ; m3devel > *Subject:* Re: [M3devel] Another m3gdb breakage > > > On 6/17/21 12:18 PM, Jay K wrote: >> Also what is expected? >> What is old output? > print argVal shows the fields. (argVal is an object.) > print RT0.Typecell (a type) gives file name and line number of type declaration >> Is it the underscores vs. the dots? > These are equivalent, should give same results >> Maybe my changes in m3front related to typenames? >> I can maybe meet my goals with less change. >> I mean, I maybe changed the IR a bit here and can maybe do less change or feed old data and new. >> >> - Jay >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* M3devel on behalf of Jay K >> *Sent:* Thursday, June 17, 2021 10:14:36 AM >> *To:* rodney.m.bates at acm.org ; m3devel >> *Subject:* Re: [M3devel] Another m3gdb breakage >> Details? >> Broken by:? >> Newer gcc? >> Newer ld? >> Newer mod? >> Newer gcc/ld flags? >> >> Last known working:? >> Recently? >> Long ago? >> Never known to work but should work? >> >> - Jay >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* M3devel on behalf of Rodney M. Bates >> *Sent:* Thursday, June 17, 2021 10:03:52 AM >> *To:* m3devel >> *Subject:* [M3devel] Another m3gdb breakage >> Breakpoint 1, PrepArg (formal=16_00000000037f5e70, actExpr=16_00000000037a6b18) >> at ../src/values/Formal.m3:605 >> 605 Error.ID (formVal.name, >> Current language: auto; currently Modula-3 >> (m3gdb) p formVal >> Can't find RT0.Typecell. Maybe M3 libraries are compiled without debug info, or not stabs. >> >> (m3gdb) p RT0.Typecell >> Can't find Modula-3 qualified reference: RT0.Typecell >> (m3gdb) p RT0__Typecell >> Can't find Modula-3 identifier: RT0__Typecell >> (m3gdb) p RTType.NULL_typecell >> $1 = RECORD typecode = 0; selfID = 1223456110; fp = {110, 117, 108, 108, 0, 0, 128, 36}; >> traced = 0; kind = 1; link_state = 1; dataAlignment = 1; dataSize = 0; type_map = NIL; >> gc_map = NIL; type_desc = NIL; initProc = NIL; brand_ptr = NIL; >> name = 16_00000000008ae080; next = NIL; END >> >> objdump -g RT0_i.o gives: >> ... >> struct MN_Eic7CJ { /* id 99 */ >> int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ >> }; >> struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ >> int64 Eic7CJ; /* bitsize 64, bitpos 0 */ >> }; >> ... >> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Cdc5c720e51264f7409ad08d931ee44d1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595721699206175%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o1pj2wmc%2FxBJ6EnsCVKQMejQDB8yWwcAwf4pqSRIHOE%3D&reserved=0 > > >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Cdc5c720e51264f7409ad08d931ee44d1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595721699316129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ihxZXRSxTATOMAWsjVeY9x%2FJ5ahiV6nHEvnFnBecX9k%3D&reserved=0 >> > > -- > Rodney Bates > rodney.m.bates at acm.org > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Cdc5c720e51264f7409ad08d931ee44d1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595721699316129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ihxZXRSxTATOMAWsjVeY9x%2FJ5ahiV6nHEvnFnBecX9k%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jun 18 11:00:48 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 18 Jun 2021 09:00:48 +0000 Subject: [M3devel] Another m3gdb breakage In-Reply-To: References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop> , , Message-ID: > Perhaps m3cc is prefixing module to typenames and can stop doing that? Indeed it is. As noted, that is only a partial solution. What do you think of something like: https://github.com/modula3/cm3/pull/677/files ? - It was correct, I broke it? - It was ok, what I did was ok? At least if I had tested and updated m3cc? - Much nicer, but again, don't let it break. ? - Other? I understand the dot vs. underscores thing. Is there a strong preference or either is ok? I have a strong preference in m3c, that they be legal C identifiers. But I can fixup things in m3c. I already do that sort of stuff. m3front for its part, already has both notions, sometimes dots, sometimes underscores. We can make it conditional on backend. I think llvm backend prefers my way but I'm not sure it does anything really. I haven't tested this yet but it looks convincing. - Jay ________________________________ From: Jay K Sent: Friday, June 18, 2021 2:20 AM To: rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] Another m3gdb breakage In m3c ?they? end up in the generated C. When compiling individual files, the names don?t really matter. When concatenating ?all? the files, such as that make up cm3, along with hand written m3core.h and *.c, the names need to match the hand written code. So then ?they? matter. However ?they? is ambiguous. Specifically the declare_typename calls were problematic. I?d fix them, and find more problems, repeatedly. What worked much better in the end was passing contextual typenames at each use, like in declare_param and import_global. The biggest problem from memory was discerning int and const_int. They are different at the C level (actual readonly efficiently cachacheable shareable memory) but hash the same because Modula3 has no provision for such optimization in its type system, alas. I went to some pain to make typenames fully qualified: Module__type. Previously, sometimes they were, sometimes not, depending on what the original Modula3 source looked like. I Iater noticed the comment that typenames are implicitly contextual. For example types can be names in procedures and probably blocks therein. Modules are not the only name scope. For now I am only interested in parameter and return type names. Locals? names in time might be interesting but it is way out there. I still think some notion of ?fully qualified? typename coming from m3front makes sense, alleviating possible backend duplication. Maybe both, prior contextual and new fully qualified? Perhaps m3cc is prefixing module to typenames and can stop doing that? Anyway I will try to look at it. - Jay ________________________________ From: Rodney M. Bates Sent: Thursday, June 17, 2021 5:15:52 PM To: Jay K ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] Another m3gdb breakage It's typename changes that did it. From an objdump -g of an old RT0_i.o that I was able to find: struct MN_Eic7CJ { /* id 75 */ int64 RT0.Typecell; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.Typecell { /* id 76 */ int64 Eic7CJ; /* bitsize 64, bitpos 0 */ }; struct MN_AjiXrU { /* id 77 */ int64 RT0.ObjectTypeDefn; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.ObjectTypeDefn { /* id 78 */ int64 AjiXrU; /* bitsize 64, bitpos 0 */ }; struct MN_CoL0WS { /* id 79 */ int64 RT0.ObjectTypecell; /* bitsize 64, bitpos 0 */ }; From Current: struct MN_Eic7CJ { /* id 99 */ int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ int64 Eic7CJ; /* bitsize 64, bitpos 0 */ }; struct MN_AjiXrU { /* id 101 */ int64 RT0.RT0__ObjectTypeDefn; /* bitsize 64, bitpos 0 */ }; struct Mn_zzzzzz_RT0.RT0__ObjectTypeDefn { /* id 102 */ int64 AjiXrU; /* bitsize 64, bitpos 0 */ }; struct MN_CoL0WS { /* id 103 */ int64 RT0.RT0__ObjectTypecell; /* bitsize 64, bitpos 0 */ }; The names already had an "RT0." prefix. Now they have "RT0.RT0__ prefix". I don't know if type names from m3front end up elsewhere besides debug entries for types, but for debug info, they need to stay as they were. On 6/17/21 12:39 PM, Jay K wrote: > I have a feeling it is my changes in m3front. > It almost seems backwards. > I was trying to preserve typenames more and give backends more information. > But in doing so I must have somehow taken information away from m3cc. > Old vs. new IR for RT0_i will probably make it clearer what I broke and what m3cc/m3gdb require. > Hopefully we can satisfy both m3cc and m3c. > Not m3c per se -- it was already working -- but the concatenate all the files scenario. > > Or maybe it is gcc/ld/flags, maybe. > In which case, easy enough, just a little "icky", can conditionalize them on backend mode. > > - Jay > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Rodney M. Bates > *Sent:* Thursday, June 17, 2021 5:32 PM > *To:* Jay K ; rodney.m.bates at acm.org ; m3devel > *Subject:* Re: [M3devel] Another m3gdb breakage > > > On 6/17/21 12:18 PM, Jay K wrote: >> Also what is expected? >> What is old output? > print argVal shows the fields. (argVal is an object.) > print RT0.Typecell (a type) gives file name and line number of type declaration >> Is it the underscores vs. the dots? > These are equivalent, should give same results >> Maybe my changes in m3front related to typenames? >> I can maybe meet my goals with less change. >> I mean, I maybe changed the IR a bit here and can maybe do less change or feed old data and new. >> >> - Jay >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* M3devel on behalf of Jay K >> *Sent:* Thursday, June 17, 2021 10:14:36 AM >> *To:* rodney.m.bates at acm.org ; m3devel >> *Subject:* Re: [M3devel] Another m3gdb breakage >> Details? >> Broken by:? >> Newer gcc? >> Newer ld? >> Newer mod? >> Newer gcc/ld flags? >> >> Last known working:? >> Recently? >> Long ago? >> Never known to work but should work? >> >> - Jay >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* M3devel on behalf of Rodney M. Bates >> *Sent:* Thursday, June 17, 2021 10:03:52 AM >> *To:* m3devel >> *Subject:* [M3devel] Another m3gdb breakage >> Breakpoint 1, PrepArg (formal=16_00000000037f5e70, actExpr=16_00000000037a6b18) >> at ../src/values/Formal.m3:605 >> 605 Error.ID (formVal.name, >> Current language: auto; currently Modula-3 >> (m3gdb) p formVal >> Can't find RT0.Typecell. Maybe M3 libraries are compiled without debug info, or not stabs. >> >> (m3gdb) p RT0.Typecell >> Can't find Modula-3 qualified reference: RT0.Typecell >> (m3gdb) p RT0__Typecell >> Can't find Modula-3 identifier: RT0__Typecell >> (m3gdb) p RTType.NULL_typecell >> $1 = RECORD typecode = 0; selfID = 1223456110; fp = {110, 117, 108, 108, 0, 0, 128, 36}; >> traced = 0; kind = 1; link_state = 1; dataAlignment = 1; dataSize = 0; type_map = NIL; >> gc_map = NIL; type_desc = NIL; initProc = NIL; brand_ptr = NIL; >> name = 16_00000000008ae080; next = NIL; END >> >> objdump -g RT0_i.o gives: >> ... >> struct MN_Eic7CJ { /* id 99 */ >> int64 RT0.RT0__Typecell; /* bitsize 64, bitpos 0 */ >> }; >> struct Mn_zzzzzz_RT0.RT0__Typecell { /* id 100 */ >> int64 Eic7CJ; /* bitsize 64, bitpos 0 */ >> }; >> ... >> >> >> -- >> Rodney Bates >> rodney.m.bates at acm.org >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Cdc5c720e51264f7409ad08d931ee44d1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595721699206175%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o1pj2wmc%2FxBJ6EnsCVKQMejQDB8yWwcAwf4pqSRIHOE%3D&reserved=0 > > >> >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Cdc5c720e51264f7409ad08d931ee44d1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595721699316129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ihxZXRSxTATOMAWsjVeY9x%2FJ5ahiV6nHEvnFnBecX9k%3D&reserved=0 >> > > -- > Rodney Bates > rodney.m.bates at acm.org > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm3lists.elegosoft.com%2Fmailman%2Flistinfo%2Fm3devel&data=04%7C01%7C%7Cdc5c720e51264f7409ad08d931ee44d1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637595721699316129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ihxZXRSxTATOMAWsjVeY9x%2FJ5ahiV6nHEvnFnBecX9k%3D&reserved=0 > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Jun 18 19:16:03 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Jun 2021 12:16:03 -0500 Subject: [M3devel] Another m3gdb breakage In-Reply-To: References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop>

Message-ID: <2867ff6c-2a36-20ec-d1c0-ef40a6964efb@lcwb.coop> Maybe you have already looked at this, but if not, here are excerpts of RT0.ic relevant to RT0.Typecell, from a cm3 compiler built in August 2018 and a recent one. Before: declare_typename -121140431 Typecell declare_typename 525366010 ObjectTypeDefn declare_typename -1868825314 ObjectTypecell declare_typename -1997175867 ArrayTypeDefn declare_typename 175486633 ArrayTypecell After: declare_typename -121140431 RT0__Typecell declare_typename 525366010 RT0__ObjectTypeDefn declare_typename -1868825314 RT0__ObjectTypecell declare_typename -1997175867 RT0__ArrayTypeDefn declare_typename 175486633 RT0__ArrayTypecell On 6/18/21 4:00 AM, Jay K wrote: >> Perhaps m3cc is prefixing module to typenames and can stop doing that? > > Indeed it is. > As noted, that is only a partial solution. > > What do you think of something like: > > https://github.com/modula3/cm3/pull/677/files > > ? > > ?- It was correct, I broke it? > ?- It was ok, what I did was ok? At least if I had tested and updated m3cc? > ?- Much nicer, but again, don't let it break. ? > ?- Other? > > I understand the dot vs. underscores thing. > Is there a strong preference or either is ok? > > I have a strong preference in m3c, that they be legal C identifiers. > But I can fixup things in m3c. I already do that sort of stuff. > m3front for its part, already has both notions, sometimes dots, sometimes underscores. > We can make it conditional on backend. > > I think llvm backend prefers my way but I'm not sure it does anything really. > > I haven't tested this yet but it looks convincing. > > ?- Jay > > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Fri Jun 18 19:20:36 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 18 Jun 2021 17:20:36 +0000 Subject: [M3devel] Another m3gdb breakage In-Reply-To: <2867ff6c-2a36-20ec-d1c0-ef40a6964efb@lcwb.coop> References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop>

, <2867ff6c-2a36-20ec-d1c0-ef40a6964efb@lcwb.coop> Message-ID: That is what I suspected. Can that be ok, with other compensating changes, or it really must be as it was? - Jay ________________________________ From: Rodney M. Bates Sent: Friday, June 18, 2021 10:16:03 AM To: Jay K ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] Another m3gdb breakage Maybe you have already looked at this, but if not, here are excerpts of RT0.ic relevant to RT0.Typecell, from a cm3 compiler built in August 2018 and a recent one. Before: declare_typename -121140431 Typecell declare_typename 525366010 ObjectTypeDefn declare_typename -1868825314 ObjectTypecell declare_typename -1997175867 ArrayTypeDefn declare_typename 175486633 ArrayTypecell After: declare_typename -121140431 RT0__Typecell declare_typename 525366010 RT0__ObjectTypeDefn declare_typename -1868825314 RT0__ObjectTypecell declare_typename -1997175867 RT0__ArrayTypeDefn declare_typename 175486633 RT0__ArrayTypecell On 6/18/21 4:00 AM, Jay K wrote: >> Perhaps m3cc is prefixing module to typenames and can stop doing that? > > Indeed it is. > As noted, that is only a partial solution. > > What do you think of something like: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fpull%2F677%2Ffiles&data=04%7C01%7C%7C655378b87c4d4a8361ed08d9327cca08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637596333820001601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XrQI0KxmjKBY5cr4mCB5A3hPEmJwxGcHrEMknWXKw44%3D&reserved=0 > > ? > > - It was correct, I broke it? > - It was ok, what I did was ok? At least if I had tested and updated m3cc? > - Much nicer, but again, don't let it break. ? > - Other? > > I understand the dot vs. underscores thing. > Is there a strong preference or either is ok? > > I have a strong preference in m3c, that they be legal C identifiers. > But I can fixup things in m3c. I already do that sort of stuff. > m3front for its part, already has both notions, sometimes dots, sometimes underscores. > We can make it conditional on backend. > > I think llvm backend prefers my way but I'm not sure it does anything really. > > I haven't tested this yet but it looks convincing. > > - Jay > > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayk123 at hotmail.com Fri Jun 18 19:37:40 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 18 Jun 2021 17:37:40 +0000 Subject: [M3devel] Another m3gdb breakage In-Reply-To: References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop>

, <2867ff6c-2a36-20ec-d1c0-ef40a6964efb@lcwb.coop>, Message-ID: Actually, ok, in terms of compensating changes, I can trim to ?__? in m3cc. Trivial. Unless, like, you insist on no m3cc changes. This will at least restore the critical RT0. It might still leave changes to typenames nested in procedures and blocks, which I suspect didn?t work right (same full name produced by m3cc for different types). - Jay ________________________________ From: Jay K Sent: Friday, June 18, 2021 10:20:36 AM To: rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] Another m3gdb breakage That is what I suspected. Can that be ok, with other compensating changes, or it really must be as it was? - Jay ________________________________ From: Rodney M. Bates Sent: Friday, June 18, 2021 10:16:03 AM To: Jay K ; rodney.m.bates at acm.org ; m3devel Subject: Re: [M3devel] Another m3gdb breakage Maybe you have already looked at this, but if not, here are excerpts of RT0.ic relevant to RT0.Typecell, from a cm3 compiler built in August 2018 and a recent one. Before: declare_typename -121140431 Typecell declare_typename 525366010 ObjectTypeDefn declare_typename -1868825314 ObjectTypecell declare_typename -1997175867 ArrayTypeDefn declare_typename 175486633 ArrayTypecell After: declare_typename -121140431 RT0__Typecell declare_typename 525366010 RT0__ObjectTypeDefn declare_typename -1868825314 RT0__ObjectTypecell declare_typename -1997175867 RT0__ArrayTypeDefn declare_typename 175486633 RT0__ArrayTypecell On 6/18/21 4:00 AM, Jay K wrote: >> Perhaps m3cc is prefixing module to typenames and can stop doing that? > > Indeed it is. > As noted, that is only a partial solution. > > What do you think of something like: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fpull%2F677%2Ffiles&data=04%7C01%7C%7C655378b87c4d4a8361ed08d9327cca08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637596333820001601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XrQI0KxmjKBY5cr4mCB5A3hPEmJwxGcHrEMknWXKw44%3D&reserved=0 > > ? > > - It was correct, I broke it? > - It was ok, what I did was ok? At least if I had tested and updated m3cc? > - Much nicer, but again, don't let it break. ? > - Other? > > I understand the dot vs. underscores thing. > Is there a strong preference or either is ok? > > I have a strong preference in m3c, that they be legal C identifiers. > But I can fixup things in m3c. I already do that sort of stuff. > m3front for its part, already has both notions, sometimes dots, sometimes underscores. > We can make it conditional on backend. > > I think llvm backend prefers my way but I'm not sure it does anything really. > > I haven't tested this yet but it looks convincing. > > - Jay > > -- Rodney Bates rodney.m.bates at acm.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Fri Jun 18 22:36:02 2021 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Fri, 18 Jun 2021 15:36:02 -0500 Subject: [M3devel] Another m3gdb breakage In-Reply-To: References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop>

<2867ff6c-2a36-20ec-d1c0-ef40a6964efb@lcwb.coop> Message-ID: <06c13092-4bb3-b2c1-e4b6-78e5da0e0b17@lcwb.coop> I have no objection to m3cc changes. Nor to m3gdb changes, if they are not extensive, now that I am once again able to compile it. (BTW, there are unresolved issues related to that, in light of header file changes etc. in newer distributions.) However, this could be delicate and pervasive. m3gdb provides a large variety of ways of naming things in user commands, in two fundamentally different categories: linespeds and expressions. These are partly inherited from gdb and partly added Modula-3 support. See doc/help/m3gdb/m3gdb-onepage.html#linespecs and #expressions for details. So m3gdb needs to be able to demangle things to individual source identifiers to allow the user to put them together in various ways. Of particular concern is the fact that it has to do this without prior knowledge whether it is a type or not, nested in procedures, etc. AFAIK, these all were working. Also, it works with the integrated back end, and I would not want to lose that. On 6/18/21 12:37 PM, Jay K wrote: > Actually, ok, in terms of compensating changes, I can trim to ?__? in m3cc. > Trivial. > > Unless, like, you insist on no m3cc changes. > > This will at least restore the critical RT0. > > It might still leave changes to typenames nested in procedures and blocks, which I suspect didn?t work right (same full name produced by m3cc for different types). > > - Jay > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Jay K > *Sent:* Friday, June 18, 2021 10:20:36 AM > *To:* rodney.m.bates at acm.org ; m3devel > *Subject:* Re: [M3devel] Another m3gdb breakage > That is what I suspected. > Can that be ok, with other compensating changes, or it really must be as it was? > > - Jay > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > *From:* Rodney M. Bates > *Sent:* Friday, June 18, 2021 10:16:03 AM > *To:* Jay K ; rodney.m.bates at acm.org ; m3devel > *Subject:* Re: [M3devel] Another m3gdb breakage > Maybe you have already looked at this, but if not, here are > excerpts of RT0.ic relevant to RT0.Typecell, from a cm3 compiler > built in August 2018 and a recent one. > > > Before: > > ??????? declare_typename???????? -121140431 Typecell > ??????? declare_typename???????? 525366010 ObjectTypeDefn > ??????? declare_typename???????? -1868825314 ObjectTypecell > ??????? declare_typename???????? -1997175867 ArrayTypeDefn > ??????? declare_typename???????? 175486633 ArrayTypecell > > After: > > ??????? declare_typename???????? -121140431 RT0__Typecell > ??????? declare_typename???????? 525366010 RT0__ObjectTypeDefn > ??????? declare_typename???????? -1868825314 RT0__ObjectTypecell > ??????? declare_typename???????? -1997175867 RT0__ArrayTypeDefn > ??????? declare_typename???????? 175486633 RT0__ArrayTypecell > > > > On 6/18/21 4:00 AM, Jay K wrote: >>> Perhaps m3cc is prefixing module? to typenames and can stop doing that? >> >> Indeed it is. >> As noted, that is only a partial solution. >> >> What do you think of something like: >> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmodula3%2Fcm3%2Fpull%2F677%2Ffiles&data=04%7C01%7C%7C655378b87c4d4a8361ed08d9327cca08%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637596333820001601%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XrQI0KxmjKBY5cr4mCB5A3hPEmJwxGcHrEMknWXKw44%3D&reserved=0 >> >> ? >> >>? ?- It was correct, I broke it? >>? ?- It was ok, what I did was ok? At least if I had tested and updated m3cc? >>? ?- Much nicer, but again, don't let it break. ? >>? ?- Other? >> >> I understand the dot vs. underscores thing. >> Is there a strong preference or either is ok? >> >> I have a strong preference in m3c, that they be legal C identifiers. >> But I can fixup things in m3c. I already do that sort of stuff. >> m3front for its part, already has both notions, sometimes dots, sometimes underscores. >> We can make it conditional on backend. >> >> I think llvm backend prefers my way but I'm not sure it does anything really. >> >> I haven't tested this yet but it looks convincing. >> >>? ?- Jay >> >> -- > Rodney Bates > rodney.m.bates at acm.org > > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel > -- Rodney Bates rodney.m.bates at acm.org From jayk123 at hotmail.com Sat Jun 19 01:59:08 2021 From: jayk123 at hotmail.com (Jay K) Date: Fri, 18 Jun 2021 23:59:08 +0000 Subject: [M3devel] Another m3gdb breakage In-Reply-To: <06c13092-4bb3-b2c1-e4b6-78e5da0e0b17@lcwb.coop> References: <3ab356af-a73a-4348-4a7a-d4c7f5aebe1b@lcwb.coop> <73216f12-aab9-f31a-6f49-2543b5b6db5d@lcwb.coop>