<sorear>
33-bit/65-bit data types are kind of gross, you need multiple precision arithmetic in the decoder, except you don't because sections filling more than half the address space don't really need to be supported
<sorear>
is there a changelog for the article? wondering how much was gained with the latest repr change
ntwk has quit [Read error: Connection reset by peer]
<meowray>
sorear: 65-bit does not need a multi-prec arithmetic. Just special case the first byte (which would be done anyway for an efficient encoder/decoder). See "Example C++ encoder:" :) There is no changelog
<meowray>
In a -O3 -g -gpubnames -gsplit-dwarf build, this approach yields a 14.8% .relleb*/.rel* size ratio, compared to 23.1% without it.
<meowray>
a rtld implementation could also ignore the most significant bit in the address space
<sorear>
didn't the example code support decoding earlier?
<sorear>
at this point it's less clear why we're using LEB128, since we lost the ability to describe encoding and decoding in a single page of code
<meowray>
sorear: what is "support decoding earlier"? (I just updated the page to add an example decoder, not that longer than the code without the even/odd offset trick)
<sorear>
since there's no changelog for the page I only have my own fallible memory to go on that there used to be an example decoder
<meowray>
there wasn't :( i just added the decoder with the even/odd offset trick
<meowray>
as long as encode[US]LEB128/decode[US]LEB128 are already available as library routines, adding the trick does not take much more lines
<sorear>
what's the - 0x40 doing?
<sorear>
oh, compensating for the lack of masking two lines previously
ntwk has joined #riscv
<meowray>
yes, a small trick. efficient leb128 encoder/decoders may unroll the first or two loops. we did a manual unroll to account for the even/odd bit
Armand has quit [Remote host closed the connection]
armand_ has joined #riscv
<sorear>
i feel like a line has to be drawn somewhere to avoid defining a full data compression algorithm
armand_ has quit [Remote host closed the connection]
Armand has joined #riscv
<meowray>
sorear: yes. i feel that this is likely the final form. adding more stuff would decrease elegance.
Armand has quit [Ping timeout: 264 seconds]
<meowray>
"In a -O1 -g build, .relleb*/.rel* size ratio drops from 21.1% to 11.2%". Debug builds were my motivation adding this trick
hightower3 has joined #riscv
hightower2 has quit [Ping timeout: 264 seconds]
aredridel4 has quit [Remote host closed the connection]
aredridel4 has joined #riscv
mewd has left #riscv [ERC 5.6-git (IRC client for GNU Emacs 30.0.50)]
Leopold has quit [Remote host closed the connection]
Leopold has joined #riscv
Guest19 has quit [Ping timeout: 250 seconds]
Armand has joined #riscv
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
pabs3 has joined #riscv
jacklsw has quit [Ping timeout: 264 seconds]
Guest19 has joined #riscv
Guest89 has joined #riscv
Guest19 has quit [Ping timeout: 250 seconds]
danilogondolfo has quit [Ping timeout: 255 seconds]
davidlt has quit [Ping timeout: 264 seconds]
davidlt has joined #riscv
davidlt has quit [Remote host closed the connection]
davidlt has joined #riscv
Armand has quit [Ping timeout: 268 seconds]
danilogondolfo has joined #riscv
danilogondolfo has quit [Remote host closed the connection]
danilogondolfo has joined #riscv
Tenkawa has joined #riscv
Armand has joined #riscv
danilogondolfo has quit [Read error: Connection reset by peer]
danilogondolfo has joined #riscv
elastic_dog has quit [Ping timeout: 260 seconds]
danilogondolfo has quit [Remote host closed the connection]
heat_ has joined #riscv
danilogondolfo has joined #riscv
elastic_dog has joined #riscv
psydroid has joined #riscv
germ is now known as germtoo
germtoo is now known as germ
germ is now known as mipseb
mipseb is now known as germ
germ is now known as germtoo
mps has quit [Remote host closed the connection]
mps has joined #riscv
jacklsw has joined #riscv
davidlt has quit [Ping timeout: 252 seconds]
luca_ has joined #riscv
luca_ is now known as OwlWizard
Guest89 has quit [Ping timeout: 250 seconds]
Armand has quit [Ping timeout: 264 seconds]
Armand has joined #riscv
Armand has quit [Remote host closed the connection]
Armand has joined #riscv
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #riscv
naoki has joined #riscv
naoki has quit [Client Quit]
Leopold has quit [Ping timeout: 260 seconds]
Leopold has joined #riscv
OwlWizard has quit [Quit: OwlWizard]
Armand has quit [Ping timeout: 264 seconds]
crossdev has quit [Read error: Connection reset by peer]
erg_ has joined #riscv
junaid_ has quit [Ping timeout: 260 seconds]
davidlt has joined #riscv
davidlt has quit [Remote host closed the connection]
davidlt has joined #riscv
emilknievel_ is now known as emilknievel
junaid_ has joined #riscv
mlw has quit [Ping timeout: 264 seconds]
mlw has joined #riscv
Stat_headcrabed has joined #riscv
dh` has quit [Ping timeout: 264 seconds]
mlw has quit [Read error: Connection reset by peer]
ldevulder has quit [Quit: Leaving]
mlw has joined #riscv
EchelonX has joined #riscv
EchelonX has quit [Client Quit]
jacklsw has quit [Ping timeout: 252 seconds]
BootLayer has joined #riscv
JanC is now known as Guest1840
JanC has joined #riscv
Guest1840 has quit [Ping timeout: 264 seconds]
junaid_ has quit [Quit: Lost terminal]
dh` has joined #riscv
vagrantc has joined #riscv
erg_ has quit [Ping timeout: 255 seconds]
<meowray>
sorear: a simpler encoding seems to work better: (offset*8+(symidx_changes?1:0)+(type_changes?2:0)+(addend_changes?4:0), optional delta_symidx, optional delta_type, optional delta_addend
<meowray>
the header (currently just the relocation count) can encode the shift value for offset (e.g. 4 for aarch64, 2 for RVC)
<meowray>
(addend_changes?4:0) takes the position of bit 2 because of another trick (not sure worth doing): the offset field can steal the addend bit, taking bits [2..63] in case addend is omitted (indicated by the header)
smaeul has quit [Ping timeout: 272 seconds]
danilogondolfo has quit [Quit: Leaving]
fuwei has quit [Quit: Konversation terminated!]
smaeul has joined #riscv
Trifton has quit [Quit: Client exited]
emilknievel has quit [Ping timeout: 264 seconds]
emilknievel has joined #riscv
crossdev has joined #riscv
erg_ has joined #riscv
crossdev has quit [Ping timeout: 268 seconds]
junaid_ has joined #riscv
BootLayer has quit [Quit: Leaving]
motherfsck has quit [Quit: quit]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
cow321 has quit [Remote host closed the connection]
<sorear>
it's a pity ia-64 relocs use bits 0,1, and 4+ of the offset
<sorear>
meowray: is it still useful to encode the fields as deltas now that we aren't relying on "LEB(0) is 1 byte" for space saving purposes?
Trifton has joined #riscv
<sorear>
(mostly for symbols)
<meowray>
sorear: still useful, more noticeable for addend (.data+0,.data+4,.data+8,...), type (R_AARCH64_* start at 257(static)/dynamic(1024)), less for symidx
<meowray>
sorear: the previous revision does uses raw symidx instead of delta symidx. with the new CREL, i feel that consistency makes delta symidx a nice choice
<meowray>
CREL beats the latest RELLEB even if the shifted offset technique is not employed.
<sorear>
I don't necessarily disagree re. consistency
<meowray>
sorear: if a DSO has 100 GOT/PLT relocations. delta symidx allows one-byte encoding for every relocation. this is a very negligible optimization, tho
<sorear>
non-delta symidx allows you to sort the symbol table by frequency of usage
<meowray>
experiments table is wip. i need to re-run builds and fill in the cells:) more complete now
<meowray>
sorear: frequency of usage optimization appears to be static relocation only. delta symidx allows optimization as well by placing hot symbols in the middle
<sorear>
"hot symbols in the middle" doesn't really help, you still have delta encoding turning a single isolated cold symbol into two adjacent large deltas
<meowray>
cold0 | hot | cold1. this issue is how often consecutive relocations switch from cold0 to cold1
<sorear>
if you have a single hot symbol in a run of cold symbols, delta encoding doesn't even notice because cold->hot and hot->cold are likely to be large
<sorear>
cold0->cold0 and cold0->cold1 are the same size 6/7 of the time, because even within cold0 you're likely to span much of the range
<sorear>
the cold symbols are far apart from each other, not just the hot ones
<meowray>
sorear: i agree that (cold0 | hot | cold1) slightly mitigates the frequency loss and does not have the full power of absolute symidx.
<meowray>
shall we switch to absolute symidx and drop the consistency here?
<meowray>
i think we should, to make use of symbol index [64,128)
<sorear>
tough to say. at this point I'm mostly arguing for not rejecting the possibility out of hand
<meowray>
for the very first revision, i tried both absolute symidx and delta symidx, and found that delta symidx had slight size increase.
<sorear>
i think that most of the benefit from absolute symidx requires adaptive entropy coding stuff that i have no interest in persuing here
<sorear>
not that CREL really makes sense for static PIE but it'll be easy to enable by accident
<meowray>
i placed the fields in this order: symidx(1)/type(2)/addend(4), because addends are mostly likely to be the same, then types, finally symidxes
<meowray>
this is not bad:) offset(uleb),symidx(uleb) , type(sleb),addend(sleb)
<meowray>
sorear: yes (dlstart.c). this is how DT_AARCH64_AUTH_RELR made me concered as well
<meowray>
it seems like elf implementation of Apple's arm64e stuff. The patches are slowly being upstreamed
<sorear>
assuming that's a PAuth vtables ABI thing, that makes a lot more sense to use in static PIE than CREL
<meowray>
CREL does not intend to replace RELR. CREL is much larger than RELR
Tenkawa has quit [Quit: Was I really ever here?]
<meowray>
sorear: DT_AARCH64_AUTH_RELR did make me wonder whether we need a generic RELR (in my blog post). i eventually accepted this duplicate
<sorear>
generic in what sense?
<sorear>
the large object file I have handiest has ~half of its relocations R_RISCV_NONE, I am thinking this is likely not normal
heat_ has quit [Remote host closed the connection]
naoki has joined #riscv
<meowray>
sorear: using a RELR-style bitmap encoding for JUMP_SLOT/GLOB_DAT. "A generalized RELR format would leverage the dyamic relocation properties well"
<meowray>
R_RISCV_NONE looks like assembler issues?
<sorear>
what's DT_RELRENT?
<meowray>
DT_RELRENT = sizeof(Elf_Relr), a useless tag in the 2018 ABI.
<meowray>
technically, it would allow extensibility, but nobody will extend it, i guess
<sorear>
what is Elf_Relr? the RELR format isn't defined in terms of structs
<sorear>
(I'm scared of Elf_Crel, it seems to serve no purpose other than to enable misuse)
<meowray>
sorear: Elf_Crel is in-memory representation. perhaps i should just remove it from the proposal. it is implementation detail
naoki has quit [Quit: naoki]
<meowray>
sorear: symidx dilemma solved. abs symidx (uleb128) somehow is larger for both x86 and aarch64 -O3 builds :)
<sorear>
should there be a CRELSZ with the compressed size?
<meowray>
sorear: seems unneeded. i thought about "header0 entry_groups0 header1 entry_groups1 ...", which would need a CRELSZ. but writing loops for N decoders in LLVM made me sad and i rejected doing this:)
lagash has joined #riscv
<sorear>
if the offset and header were also slebs it would simplify standalone decoders a bit, likewise a guarantee that there will be no overlong sequences
<meowray>
sorear: yes. using sleb for offset, however, would increase .o size slightly significantly
<meowray>
sorear: technically, we could also use zigzag encoding ((i>>31) ^ (i<<1)) to convert the two int32_t sleb128 to use uleb128 instead.
<meowray>
but i believe zigzag encoding has poor performance (unneeded bitwise operations) when the majority cases fit into one byte