***tanvirroshid9 is now known as tanvirroshid
<rekado_>getting closer to building a ghc 4 with debug symbols. <rekado_>they do everything manually; the perl script “ghc-asm.prl” strips the generated binaries, and they use bfd to provide custom debug symbols. <rekado_>all this custom futzing around with the binaries means that I can’t deviate much from the tools of that era <rekado_>it must be a pretty old binutils and gcc, but old binutils doesn’t work well with a more recent libc. <rekado_>I’ve built the compiler now, but gdb doesn’t seem to do anything with the DEBUG_LoadSymbols definition <rekado_>do any of you know how to make use of a definition of “extern void DEBUG_LoadSymbols” when using gdb? <rekado_>(maybe this is just GHC-specific and nobody else does this kind of thing) <stikonas>I'm not really GDB expert but soudns like it mightb e GHC specific <rekado_>ghc 4 doesn’t do that, so it’s good to see an example of how this is intended to be used. <stikonas>\me is trying to investigate some very strange UEFI M2libc bug... <stikonas>(looks like I used wrong slash for IRC *nick thing) <stikonas>some strange interaction between writing to file (fputc or fclose), _free_pages(_malloc_start, PAGE_NUM) function call and repeated running of my small test program (first run seems to work) <stikonas>and even stranger, re-running BOOTX64 to rebuild everything seems to mitigate the problem, it only gets stuck if I repeatedly run the same things twice <muurkha>good thing it wasn't \m hotbabe32 sure, my number is +1 730 555 1212 <stikonas>I guess some kind of memory issue, but still symptoms are very strange... <stikonas>well, hence my suspicion that there is some bad memory handling, those bugs tend to be weird <oriansj>stikonas: well we do buffer writes and if they aren't flushed it could result in truncated write results <oriansj>(we also buffer reads by just reading the whole file at once) <oriansj>muurkha: only on the internet can one pause and wonder if hotbabe32 is 32 or if he was born in 1932 or if she's an 11 year old FBI agent. <stikonas>oriansj: that's still bootstrap.c so I don't think there are buffer writes <stikonas>hmm, unlikely, let me show my test program <stikonas>and if I put exit(5); before fputc('\n', f); then it exits just fine and I can run it repeatedly (that's probably expected) <oriansj>well UEFI probably needs the \r as well <stikonas>but the stranger thing is that I can run the program witout exit (the one that can't be rerun without getting stuck) <stikonas>then the one with exit, then I can run the one without exit and it would work then <stikonas>oriansj: that is handled at bootstrap.c level <stikonas>it's still very much wip but better than nothing