IRC channel logs

2021-10-22.log

back to list of logs

<fossy>stikonas: Am i correct that the only uses of autogen in GCC are fixincludes and top-level makefile
<fossy>it seems that the vast majority of Makefile.tpl is things like FOR and IF loops
<fossy>I think we can reconstruct this as say a bash script
<fossy>(I would do Python but we don't have that yet)
<stikonas>fossy: yes, I think that's right
<stikonas>I wonder if bash script can be upstreamed
<stikonas>yeah, Python would be nicer...
<stikonas>fossy: or should we build python?
<fossy>Could do that
<stikonas>and then do autogen
<fossy>it needs a bit of bootstrap
<fossy>but not much
<stikonas>oh?
<stikonas>it uses some python scripts?
<fossy>3.10 has a couple of python scripts used to generate a few sources
<fossy>but i looked at 2.7 and it at least dosen't
<stikonas>ok, that's good
<fossy>so we aren't going into the super old if we have to
<stikonas>well, python is probably more maintainable than bash script...
<stikonas>but hmm
<stikonas>bash might be easier to upstream...
<stikonas>but I"ve no idea how receptive GCC folks would be to that...
<fossy>GCC already has a number of python scripts in contrib/
<fossy>for various "developer tools"
<fossy>i'm guessing this would be treated similarily
<stikonas>ok, so language wouldn't matter
<stikonas>well, it's just that this might be a fairly big script
<fossy>hm, what about jinja2
<stikonas>that might work
<stikonas>jinja has for loops and ifs
<fossy>its literally a templating engine, and that seems to also be all autogen is here
<stikonas>exactly
<stikonas>and we have at least some argument why autogen is not good
<stikonas>although there might be some push back due to autogen being gnu project and jinja2 not
<fossy>it being a generally unmaintained and poor piece of software
<fossy>true
<stikonas>but maybe people wouldn't care too much
<fossy>i have no problem keeping this downstream if it isn't to be upstreamed
<stikonas>we'll see...
<stikonas>so maybe let's bootstrap jinja2
<fossy>yeah, python and jinja2, then we can look at rewriting these scripts
<stikonas>in any case, we'll have to keep it downstream for gcc 10
<fossy>and 11
<stikonas>yes, and binutils
<stikonas>well, binutils maybe less so
<fossy>does binutils do the same thing :|
<stikonas>if we wait for release
<stikonas>yes, it does
<stikonas>maybe smaller templates there...
<stikonas>hmm, I can also reproduce that WHILE_handle_define_2 crash in M2-planet
<stikonas>that's cc_core.c file in M2-Planet, handle_define function
<stikonas>maybe something bad is going on with macro_token->s[0]
<stikonas>gbrlwck: it's probably best to build M2-Planet with GCC and debug that version
<stikonas>rather than bootstrapped version
<stikonas>you'll get much better debugging support
<muurkha>oriansj: I agree, no place for programming sins to hide. no, I wasn't accusing you of having an ego, just a little allergic to absolution through confession of sins :)
<muurkha>stikonas: yes, the autogen case is a pretty messy problem indeed
<stikonas>actually, GCC version does not crash but prints include/m2/lib.h:70:unexpected #endif
<muurkha>the original cvs repo is almost certainly "messed up"
<muurkha>there are probably archives of GNU tapes from before 02001 that have earlier versions of GNU source code
<stikonas>oriansj: does M2-Planet handle ifdefs and endifs?
<stikonas>muurkha: well, not if the project was not GNU project then
<stikonas>when GNU adopted autogen, it was already messed up
<stikonas>so rewriting required GCC templates in jinja2 might be the easiest path
<stikonas>and we just send autogen to the landfill
<stikonas>gbrlwck: anyway, if I remove ifdefs, I get the next crash in M2-Planet's preprocess function
<stikonas>p start_of_line
<stikonas>Cannot access memory at address 0xfffffffffffffffc
<stikonas>which is a bit strange...
<muurkha>stikonas: yeah, but I'm just guessing because that was the oldest version I found on archives of the GNU web site
<muurkha>unfortunately the IA doesn't archive FTP sites much
<muurkha>or are you saying you have independent information about when autogen became a GNU project?
<stikonas>muurkha: I don't have independent information...
<stikonas>but I found that it was not well packaged by distros before
<stikonas>so that does give some evidence to that
<muurkha>yeah
<stikonas>(once package becomes gnu project, more distros pick it up)
<muurkha>maybe
<muurkha>but certainly once a package becomes a dependency of GCC all the distros will pick it up
<muurkha>except MacOS *spit*
<stikonas>fossy: gnutls also uses autogen, actually even more
<stikonas>well, it's not a full dependency
<stikonas>GCC tarballs and even repo ship output of Autogen
<stikonas>it's just that here we don't like using pre-generated files
<stikonas>no matter how readable they are
<stikonas>(most of the times they aren't very readable)
<stikonas>fossy: ok, actually for gnutls it's an optional dependency, so probably we can ignore it
<stikonas>(only used if tools are built)
<oriansj>stikonas: M2-Planet supports #if, #elif, #else and #endif along with #define and defined
<oriansj>so one can use #if defined(__M2__) for M2-Planet only sections and an #else for things M2-Planet isn't supposed to use
<fossy>le sigh
<fossy>that's good at least
<oriansj>and I too am getting that segfault on include/m2/lib.h
<oriansj>even when built with GCC
<muurkha>yay! reproducible bugs!
<oriansj>just wish I knew why my terminal is showing me this: https://paste.debian.net/1216345/
<oriansj>but it is because expansion_end isn't initialized at that point
<oriansj>(struct*) null->next is a segfault sort of thing
<oriansj>yeah it is the line #define __M2_LIB_H
<oriansj>and I probably should add an error message for the #ifndef
<oriansj>and I'll update M2libc in M2-Planet while I am at it
<oriansj>patches for M2-Planet are now up
<siraben>Is anyone familiar with the bootstrapping situation in Emacs? AFAIK it's bootstrapped
<fossy>I will be super disappointed if emacs is not bootstrappable
<fossy>There is no reason for it to have a dependency on itself let alone be bootsteappable
<fossy>be not bootsteappable
<siraben> https://www.gnu.org/software/emacs/manual/html_node/elisp/Building-Emacs.html
<siraben>"Like ‘pdump’, but used while bootstrapping Emacs, when no previous Emacs binary and no *.elc byte-compiled Lisp files are available. The produced dump file is usually named bootstrap-emacs.pdmp in this case. "
<siraben>so looks like it is bootstrapped
<muurkha>the comment you quoted seems to say the opposite: no previous Emacs binary is needed to pull up Emacs by its bootstraps
<muurkha>instead, you can use pbootstrap, which can be compiled without Emacs
<muurkha>we should come up with a term that doesn't mean both what we are trying to achieve and also its opposite; "bootstrapping" is compiling a compiler with itself, which is what we are trying to avoid. how about "acyclic"?
<muurkha>we're trying to achieve acyclic builds
<Hagfish>nice
<muurkha>or "ken-proof builds" maybe
<Hagfish>heh
<Hagfish>instead of saying "making acyclic" could we say "decycling"?
<Hagfish>software environmentalism :)
<muurkha>upcycling!
<fossy>not sure i agree with that terminology
<fossy>i have never heard bootstrapping meaning compiling a compiler with itself
<drakonis>that's self hosting
<fossy>^
<drakonis>bootstrapping on the other hand is a chain of steps to begin something, a cycle, for example.
<drakonis>or a chain
<muurkha>the term derives from the English idiom "to pull oneself up by one's bootstraps", in violation of Newton's Third Law
<muurkha>like how the Baron von Munchausen pulled himself and his horse up out of the swamp by pulling on his braid
<muurkha>but check out this Wikipedia article: https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
<muurkha>or this question on Stack Overflow: https://stackoverflow.com/questions/1493747/bootstrapping-a-compiler-why
<muurkha>those are two of the top three hits for "bootstrapped compiler" on startpage.com
<muurkha>the third one is a geeksforgeeks article written by a muurkha
<muurkha>using the opposite definition from Wikipedia and the SO folks
<stikonas>ok, with new M2-Planet I can confirm that segfault is gone...
<stikonas>although, mes uses quite a few macros that M2-Planet is not able to cope with
<stikonas>ok, I got a bit further, at some point later I need to grab laanwj's changes to use risc-v syscalls
<stikonas>(some differ from x86)
<gbrlwck>stikonas[m]: why did you alternate between LD and ADDI instructions in https://github.com/oriansj/M2libc/pull/5/files ? aren't they equivalent?
<gbrlwck>is there a reason there is __sys_call6 but not __sys_call5?
<stikonas[m]>gbrlwck: no, they are different. LD deferences pointer but addi adds value to it
<stikonas[m]>As for syscalls, I guess we just didn't need any with 5 arguments
<muurkha>if you did you could just use __sys_call6
<muurkha>and pass a dummy sixth argument
<stikonas[m]>muurkha: I guess so
<stikonas[m]>Well, you just set some registers in assembly
<muurkha>exactly
<muurkha>if they were pushed on the stack it would be a different matter
***jackhill is now known as KM4MBG
***KM4MBG is now known as jackhill