IRC channel logs

<lanodan>DynDNS is just a DNS server detail though, more like an issue due to mooo.com being shared, like how eu.org users also tend to get into blacklists.

<stikonas>lanodan: I actually tried that link in on my work network

<stikonas>it said blocked. reason: dynamic dns

<lanodan>Huh, well that's some bullshit

<lanodan>But well it's corporate firewalls, it doesn't really works on reason and quite a lot of them are trigger happy on blocking things out

<stikonas>yeah, they sometimes block even legit pages...

<stikonas>I think I remember sometimes even make manuals on gnu.org were blocked

<jackdk>At least you can get those locally and texinfo is actually pretty decent to use (and really nice within emacs)

<matrix_bridge><gtker> stikonas: In M1, is there some way of automatically padding with zeros until a specific address? I'm having an issue with aarch64 performance falling off a cliff unless the globals are padded to 0x40f000

<matrix_bridge><Jeremiah Orians> Well you can pad to the word just using < and <123 to pad 123 bytes of zeros

<matrix_bridge><Jeremiah Orians> And we do support that sort of address calculation with labels but we haven’t needed that sort of padding yet but it would be rather simple to add in hex2

<matrix_bridge><gtker> So "<195" would append 195 null bytes?

<matrix_bridge><gtker> Ah yep, that seems to work out fine. I don't think there's any reason to add features to hex2, this will work fine

<matrix_bridge><Jeremiah Orians> Not all M0 implementations support it but M1 definitely does

<matrix_bridge><Jeremiah Orians> So one can’t leverage in cc_* situations but after M1 it is fine

<matrix_bridge><Jeremiah Orians> But cc_* generated results were never fast anyway

<matrix_bridge><gtker> Alright. Worst case I'll just manually pad with NULL defines if necessary

<matrix_bridge><Jeremiah Orians> Also, couldn’t you just move the starting address so that the globals and the code are after that address?

<matrix_bridge><gtker> I'm not sure what exactly is happening, it seems like the code and the globals need to have some amount of padding between them for some reason

<matrix_bridge><Jeremiah Orians> Neural network prefetch logic is the most likely cause

<agg1>finally, it seems portage/emerge/ebuild tooling is self-hosting with tinycc

<agg1>have to roll-back ebuilds to EAPI6 it seems, because bash.static is blocked at bash-4.1

<agg1>but, that's far less trouble than re-writing the entire packaging of ~500 ebuilds all at once

<agg1>and too, compiling a complete i586-tcc-linux2-musl.iso distribution should be decent initial runtime testing

<agg1>wasn't too trivial, moving recent software versions back onto linux2 abi compiled tinycc

<agg1>and if a complete self-hosting compilation passes, then that's probably good enough for a devdrop release of this

<matrix_bridge><cosinusoidally> Talking of hex2, is it possible to set multiple base addresses? I've converted a win32 PE file to M1 https://github.com/cosinusoidally/tcc_simple/blob/master/experiments/xp_linux/min_win32_asm.M1 but I end up having to run it through hex2 twice with different base addresses and then splice the two output files together. This kind of works, but I can't handle function pointers in the text section...

<matrix_bridge>... (since that would need absolute addresses for function pointers and data pointers, and the text/data sections have different base addresses). There's also Relative virtual addresses (RVA) to consider.

<mid-kid>agg1: shame about EAPI=6, cross compilation is kind of unusable before 7...

<agg1>mid-kid: cross-compilation was/is unstable with EAPI7|8 too

<agg1>had to patch and fiddle into many ebuilds for this

<agg1>i'm not happy EAPI6 limitation seems unavoidable

<agg1>but bug-hunting into any later than bash-4.1 is beyond my abilities

<agg1>because i've too reached a point when attaching gdb to some ebuild.sh run failed

<agg1>to see where and why bash-4.x segfaults when compiled with tinycc

<agg1>so, it's a major hallelujah, at least emerge/ebuild/crossdev can be spawn again, on some tinycc buildhost

<agg1>long-term i'm thinking to avoid gentoo/portage by re-writing this, and yes, i do not want to loose cross-compilation that i've patched and hacked already

<agg1>moment ago i've just successfully re-emerged a complete ebuild, after several month of bug hunting it's working now

<agg1>testing another one currently, which executes eautoreconf, that covers perl.static/autotools/eclasses work as these should

<agg1>which seems ok too, sigh

<matrix_bridge><Jeremiah Orians> cosinusoidally: Well, it might be possible to create something in hex2 that lets you specify a new base address inside of the file but it seems like a bad idea for many reasons.

<mid-kid>agg1: yeah, it's still a cool achievement. Congrats!

<agg1>there's a chance to repair bash-4.4 or later with tinycc, it's just beyond my abilities

<agg1>once a release is available, it should be easier to re-produce such issues, if anyone tinycc dev wanted to

<agg1>but there's a lot of work remaining, which at least i can now continue with

<matrix_bridge><cosinusoidally> Jeremiah Orians: Why would it be a bad idea? Might not be necessary at the moment but if there was a platform that must have separate data/text sections that are mapped at different locations then it could be an issue there. I might experiment with tweaking hex2 to see what this could look like for my PE file.

<matrix_bridge><cosinusoidally> Maybe something like the "foo>bar" notation but "bar" would be the alternative base address.

IRC channel logs

2025-11-20.log