whitequark changed the topic of #tinyqma to: design of an open hardware DDS-based QMA with a low-voltage dc/rf stage :: http://irclog.whitequark.org/tinyqma
<bofh__>
it brings me great sadness to say that I've actually used your idea of longjmp()'ing out of an atexit() handler not only once but twice to deal with shitty library code.
<bofh__>
anyway now that my previous contract is done I have a bit of time - I seem to recall you wanting a Matheiu stability plot generator for this at some point?
<whitequark>
mmm, yeah
<whitequark>
I'm eight hours into parsing DWARF exception handling table miscompilation by hand, so probably tomorrow
<whitequark>
this is absolutely dreadful
<bofh__>
fair, also jesus that's a fate I wouldn't wish on anyone
<bofh__>
I'll use this time to work through my "SEGVs in freetype that I think I can upgrade to code executions" list (depressingly, it has >1 entries on it. >3, in fact).
<whitequark>
haha
<whitequark>
I *think* this is a binutils bug.
<whitequark>
it would be easier to verify if it did not involve relocations that I cannot emit via an assembler stashed into a middle of a section containing binary data serialized using a variable-length encoding
<bofh__>
e
<bofh__>
is there any sensible reason that they're using a variable-length encoding to serialize said data? (why is it serialized to begin with in a binary format?)
<whitequark>
DWARF
<bofh__>
also I'd believe it's a binutils bug, every time I need to look into the codebase of libbfd I always come out a bit unnerved.
<whitequark>
debug info
<whitequark>
LLVM debug info takes ~1GB even without fancy features, anyway
<whitequark>
webkit is 8GB or so
<bofh__>
yeah, I've always viewed that as a limitation / design flaw(?) on the part of DWARF. I mean I can't claim to know how to design a better way to store debuginfo, but I'm unconvinced it needs a full stack-based VM.
<whitequark>
you can't really express arbitrary optimizations otherwise
<whitequark>
unless you are willing to develop your compiler and debugger in lockstep
<bofh__>
good point, I guess if you want your debuginfo to make sense above -O0 then that would be necessary.
<bofh__>
webkit iirc is a fun challenge in a number of ways for linkers due to the size of all of the output binaries that ld needs to link together
<whitequark>
it can't fit the list of symbols into 32-bit address space
<whitequark>
not even the files; just the symbols
<whitequark>
hrm, not a binutils bug
<whitequark>
what do you think a PC-relative relocation into a data section does?
<whitequark>
insert the difference between the address of the data and the target symbol? NOPE
<whitequark>
inserts the difference between the address of the start of the section and the target symbol.
<whitequark>
because that's totally what "PC-relative" means
<bofh__>
WTF
<bofh__>
I guess that... no, that really doesn't make any sense.
<whitequark>
this is naturally not what libunwind expects, and everything explodes