Skip to content
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

Fix parser error on undef type in argument list of tail call. #83

Merged
merged 1 commit into from
Nov 24, 2022

Conversation

hydra
Copy link
Contributor

@hydra hydra commented Nov 21, 2022

LLVM output was generated by rustc nightly-2022-11-16.

I ran into an issue with the parser in the tool and found and 'fixed' the issue.

Note: I wasn't able to run the integration tests, they ALL fail on my machine, but I don't think the code change I made is the cause. I have an underlying issue with the rustc linker failing to link targets due to an bug that is fixed, but still unreleased. (See rust-lang/rust#88704)

The specific line that fails to parse is line 3 in the example.

tail call void %1(i32 noundef 0, i32 undef) #39, !dbg !104902

Specifically, it's missing handling for undef after the i32 type.

LLVM output was generated by rustc nightly-2022-11-16.
@japaric
Copy link
Owner

japaric commented Nov 24, 2022

thanks for the fix!
bors merge

I'm curious about what kind of program would produce a call with a undef value. I would naively think that if undef appears in the llvm-ir then the program has undefined behavior but I guess it could be fine depending on the signature of the function being called.

@bors
Copy link
Contributor

bors bot commented Nov 24, 2022

Build succeeded:

@bors bors bot merged commit ed69005 into japaric:main Nov 24, 2022
@japaric
Copy link
Owner

japaric commented Nov 24, 2022

release v0.1.14 includes this fix

@hydra
Copy link
Contributor Author

hydra commented Nov 30, 2022

I'm curious about what kind of program would produce a call with a undef value. I would naively think that if undef appears in the llvm-ir then the program has undefined behavior but I guess it could be fine depending on the signature of the function being called.

Here's the code, obfuscated.

struct A {}
struct B {}

pub static mut STATIC_A: Option<A> = None;
pub static mut STATIC_B: Option<B> = None;

enum E { E1, E2(u32), E3(u32), E4 }

pub fn callback(e: E) -> () {
    unsafe {
        match (&mut B, &mut A, e) {
            (Some(b), _, E::E1) => b.b1(),
            (Some(_), Some(a), E::E2(n)) => a.a1(n as u8),
            (Some(_), Some(a), E::E3(n)) => a.a2(0xfe),
            (Some(b), _, E::E4) => b.b2(),
            (_, _, _) => (),
        }
    }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants