Skip to content

[compiler-rt][RISCV] Avoid using __init_riscv_feature_bits as a direc… #115316

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 7, 2024

Conversation

kito-cheng
Copy link
Member

…t constructor

__init_riscv_feature_bits takes an argument that can be platform-specific, potentially pointing to the VDSO address of the hwprobe system call for Linux. However, marking it as a constructor does not guarantee that 0/NULL will always be passed to this argument, which may result in treating an uninitialized or garbage value as a pointer to hwprobe, leading to a crash.

The simplest solution is to introduce a small constructor function to ensure that the platform-specific argument is set to 0/NULL.

…t constructor

`__init_riscv_feature_bits` takes an argument that can be platform-specific,
potentially pointing to the VDSO address of the hwprobe system call for Linux.
However, marking it as a constructor does not guarantee that 0/NULL will always
be passed to this argument, which may result in treating an uninitialized or
garbage value as a pointer to hwprobe, leading to a crash.

The simplest solution is to introduce a small constructor function to ensure
that the platform-specific argument is set to 0/NULL.
Copy link

github-actions bot commented Nov 7, 2024

✅ With the latest revision this PR passed the C/C++ code formatter.

Copy link
Member

@lenary lenary left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds reasonable to me.

Given your recent update to the wording in C api, can you check that the lengths are being left as zero until e.g. hwprobes are successful? The setting of lengths on (new) line 359/360 looks a little strange to me, given (new) line 369 seems to return if initHwProbe fails.

@kito-cheng
Copy link
Member Author

Given your recent update to the wording in C api, can you check that the lengths are being left as zero until e.g. hwprobes are successful? The setting of lengths on (new) line 359/360 looks a little strange to me, given (new) line 369 seems to return if initHwProbe fails.

Yeah I think that should fix as well, but let me create another PR for that :)

@kito-cheng kito-cheng merged commit 522880c into llvm:main Nov 7, 2024
7 checks passed
@kito-cheng kito-cheng deleted the kitoc/fix-riscv-feature-bits-ctor branch November 7, 2024 16:06
Groverkss pushed a commit to iree-org/llvm-project that referenced this pull request Nov 15, 2024
llvm#115316)

…t constructor

`__init_riscv_feature_bits` takes an argument that can be
platform-specific, potentially pointing to the VDSO address of the
hwprobe system call for Linux. However, marking it as a constructor does
not guarantee that 0/NULL will always be passed to this argument, which
may result in treating an uninitialized or garbage value as a pointer to
hwprobe, leading to a crash.

The simplest solution is to introduce a small constructor function to
ensure that the platform-specific argument is set to 0/NULL.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants