Let arithmetic overflows wrap when executing line programs

[fitzgen]

The DWARF spec isn't clear on how to handle overflow, but there is a small
chance some random toolchain in the wild relies on overflow to do hacky
subtraction of the current row's address. And wrapping is faster than checking
for overflow and returning an error anyways. So we just do wrapping.

/me shrugs

Fixes #506

[bjorn3]

In case of fields represented as uleb128 data, shouldn't overflow be impossible from a spec point of view? (bigint)

[philipc]

In case of fields represented as uleb128 data, shouldn't overflow be impossible from a spec point of view? (bigint)

Yes, and related to that, it probably also makes more sense for us to use u32 for line numbers. e.g that's all the backtrace-rs ends up returning. Not something for this PR though.

[philipc]

I said in #506 that I think returning an error is better, but I'm not so sure now. This is performance sensitive and doesn't currently need any error handling so I'm not keen on adding it. I also think it's quite unlikely that toolchains will intentionally do this, but maybe they do unintentionally, and it's better for us to cope as best we can? I'm pretty sure that all other consumers are going to be doing wrapping arithmetic, so if toolchains do emit this then we'd be the only ones failing to consume it.

[philipc]

Btw, CI failed (in addition to not reporting the result again...)

[fitzgen]

In case of fields represented as uleb128 data, shouldn't overflow be impossible from a spec point of view? (bigint)

This makes sense when not considering what semantic data is encoded in leb128.

For line numbers, I see the argument for big int semantically (but I don't think we should actually use big ints here).

However PCs in the line table are not big ints, they are fixed size words of the target architecture's pointer width. To be maximally correct, I think we would want to wrap or error on overflow at that target pointer width, rather than u64.

[fitzgen]

This is performance sensitive and doesn't currently need any error handling so I'm not keen on adding it. I also think it's quite unlikely that toolchains will intentionally do this, but maybe they do unintentionally, and it's better for us to cope as best we can? I'm pretty sure that all other consumers are going to be doing wrapping arithmetic, so if toolchains do emit this then we'd be the only ones failing to consume it.

Yeah, this was basically my logic as well.