11 Commits

Author SHA1 Message Date
Fangrui Song
35bf8e798d
[Support] Add decodeULEB128AndInc/decodeSLEB128AndInc
Many decodeULEB128/decodeSLEB128 users need to increment the pointer.
Add helpers to simplify this common pattern. We don't add `end` and
`error` parameters at present because many users don't need them.

Pull Request: https://github.com/llvm/llvm-project/pull/85739
2024-03-19 15:40:23 -07:00
Duo Wang
e3f16de9a3
[unittest][Support] Fix bad negation of signed integer in LEB128Test.SLEB128Size (#72700)
I came across an undefined behavior when running Support unit tests with
UBSAN on Windows.
```bash
[ RUN      ] LEB128Test.SLEB128Size
C:\llvm\unittests\Support\LEB128Test.cpp:382:3: runtime error: negation of -9223372036854775808 cannot be represented in type 'long long'; cast to an unsigned type to negate this value to itself
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior C:\llvm\unittests\Support\LEB128Test.cpp:382:3 in 
```

UBSAN did not report the same error on macOS, but the negation still
seemed invalid (`0x8000000000000000LL == -0x8000000000000000LL`
evaluated to `true`).
I can confirm that `-0x7fffffffffffffffLL - 1` results in the expected
value on both platforms.
2023-11-27 11:13:27 -08:00
Richard Smith
32e98f05fe Diagnose if a SLEB128 is too large to fit in an int64_t.
Previously we'd hit UB due to an invalid left shift operand.

Also fix the WASM emitter to properly use SLEB128 encoding instead of
ULEB128 encoding for signed fields so that negative numbers don't
result in overly-large values that we can't read back any more.

In passing, don't diagnose a non-canonical ULEB128 that fits in a uint64_t but
has redundant trailing zero bytes.

Reviewed By: dblaikie, aardappel

Differential Revision: https://reviews.llvm.org/D95510
2021-02-02 14:33:34 -08:00
Pavel Labath
8f1233699b [llvm/Support] Don't crash on empty nullptr ranges when decoding LEBs
Summary:
If the decoding functions are called with both start and end pointers
being nullptr, the function will crash due to a nullptr dereference.
This happens because the function does not recognise nullptr as a valid
end pointer.

Obviously, nobody is going to pass null pointers here deliberately, but
it can happen indirectly (as it did for me), when calling these
functions on an ArrayRef, as a default-initialized empty ArrayRef will
have both begin() and end() pointers equal to nullptr.

The fix is to simply remove the nullptr check. Passing nullptr for "end"
with a valid "begin" pointer will still work, as one cannot reach
nullptr by incrementing a valid pointer without triggerring UB.

Reviewers: dblaikie

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77304
2020-04-06 14:14:11 +02:00
Chandler Carruth
2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Sam Clegg
66a99e41cd Change encodeU/SLEB128 to pad to certain number of bytes
Previously the 'Padding' argument was the number of padding
bytes to add. However most callers that use 'Padding' know
how many overall bytes they need to write.  With the previous
code this would mean encoding the LEB once to find out how
many bytes it would occupy and then using this to calulate
the 'Padding' value.

See: https://reviews.llvm.org/D36595

Differential Revision: https://reviews.llvm.org/D37494

llvm-svn: 313393
2017-09-15 20:34:47 +00:00
Chandler Carruth
9a67b07398 Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consistently with
other utility headers.

No other change was made. I did no manual edits, all of this is
clang-format.

This should allow other changes to have more clear and focused diffs,
and is especially motivated by moving some headers into more focused
libraries.

llvm-svn: 304786
2017-06-06 11:06:56 +00:00
Dan Gohman
23a543971e [Support] Extend SLEB128 encoding support.
Add support for padded SLEB128 values, and support for writing SLEB128
values to buffers rather than to ostreams, similar to the existing
ULEB128 support.

llvm-svn: 294675
2017-02-10 00:02:58 +00:00
Nick Kledzik
d7679269a9 [Support] add decodeSLEB128()
We already have routines to encode SLEB128 as well as encode/decode ULEB128.
This last function fills out the matrix.  I'll need this for some llvm-objdump
work I am doing.

llvm-svn: 217830
2014-09-15 21:51:49 +00:00
Alex Lorenz
5117674f55 [Support] Fix the overflow bug in ULEB128 decoding.
Differential Revision: http://reviews.llvm.org/D5029

llvm-svn: 216268
2014-08-22 16:29:45 +00:00
Logan Chien
5b776b72f6 Move get[S|U]LEB128Size() to LEB128.h.
This commit moves getSLEB128Size() and getULEB128Size() from
MCAsmInfo to LEB128.h and removes some copy-and-paste code.

Besides, this commit also adds some unit tests for the LEB128
functions.

llvm-svn: 201937
2014-02-22 14:00:39 +00:00