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.

Sign up for GitHub

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

Jump to bottom

Devise a way to test debuginfo #2195

Closed
brson opened this issue Apr 12, 2012 · 3 comments
Closed

Devise a way to test debuginfo #2195

brson opened this issue Apr 12, 2012 · 3 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-testsuite Area: The testsuite used to check the correctness of rustc C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Milestone
old 1.0 milestone

Comments

@brson
Copy link
Contributor

brson commented Apr 12, 2012

Debug info is very prone to breakage. We should come up with a way to test it. Maybe look into how LLVM does it.
@ghost ghost assigned brson Apr 12, 2012
@brson
Copy link
Contributor Author

brson commented Apr 12, 2012

One obvious thing is setting up a debuginfo bot that builds everything with debug info, but we need real debuginfo tests too.

@graydon
Copy link
Contributor

graydon commented Apr 16, 2012

yeah. there are several tools that know how to dump dwarf to text, and gdb can also be driven by batch input as well as embedded python scripts. this should be very possible.

@bleibig bleibig mentioned this issue Feb 9, 2013
Closed
@brson
Copy link
Contributor Author

brson commented Feb 12, 2013

@bleibig added support to compiletest for driving gdb and interpreting the results. Considering this done, now let's use it!

@brson brson closed this as completed Feb 12, 2013
Gankra added a commit to Gankra/rust that referenced this issue Nov 1, 2017
@Gankra
Add reftest that checks the layout of repr(int) on non-c-like enums
95a7f29 
This verifies the layout specified in rfc rust-lang#2195
Gankra added a commit to Gankra/rust that referenced this issue Nov 8, 2017
@Gankra
Add reftest that checks the layout of repr(int) on non-c-like enums
e156f89 
This verifies the layout specified in rfc rust-lang#2195
petertodd added a commit to petertodd/rust that referenced this issue Dec 8, 2018
@petertodd
Add (failing) test to check order of repr(int) enum fields
8b80890 
RFC rust-lang#2195 specifies that a repr(int) enum such as:

    #[repr(u8)]
    enum MyEnum {
        B { x: u8, y: i16, z: u8 },
    }

has a layout that is equivalent to:

    #[repr(C)]
    enum MyEnumVariantB { tag: u8, x: u8, y: i16, z: u8 },

However this isn't actually implemented, with the actual layout being
roughly equivalent to:

    union MyEnumPayload {
        B { x: u8, y: i16, z: u8 },
    }

    #[repr(packed)]
    struct MyEnum {
        tag: u8,
        payload: MyEnumPayload,
    }

Thus the variant payload is *not* subject to repr(C) ordering rules, and
gets re-ordered as `{ x: u8, z: u8, z: i16 }`

The existing tests added in pull-req rust-lang#45688 fail to catch this as the
repr(C) ordering just happens to match the current Rust ordering in this
case; adding a third field reveals the problem.
emilio pushed a commit to emilio/rust that referenced this issue Dec 16, 2018
@petertodd @emilio
Add test to check order of repr(int) enum fields
d84bdba 
RFC rust-lang#2195 specifies that a repr(int) enum such as:

    #[repr(u8)]
    enum MyEnum {
        B { x: u8, y: i16, z: u8 },
    }

has a layout that is equivalent to:

    #[repr(C)]
    enum MyEnumVariantB { tag: u8, x: u8, y: i16, z: u8 },

However this isn't actually implemented, with the actual layout being
roughly equivalent to:

    union MyEnumPayload {
        B { x: u8, y: i16, z: u8 },
    }

    #[repr(packed)]
    struct MyEnum {
        tag: u8,
        payload: MyEnumPayload,
    }

Thus the variant payload is *not* subject to repr(C) ordering rules, and
gets re-ordered as `{ x: u8, z: u8, z: i16 }`

The existing tests added in pull-req rust-lang#45688 fail to catch this as the
repr(C) ordering just happens to match the current Rust ordering in this
case; adding a third field reveals the problem.
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
@bors
Auto merge of rust-lang#2195 - RalfJung:vtable-validation, r=RalfJung
03a05ae 
test for Stacked Borrows error during vtable validation

Fixes rust-lang/miri#2123
Needs rust-lang#97761
celinval pushed a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@tautschnig
Clarify the analysis technique used by Kani (rust-lang#2195)
9439a54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-testsuite Area: The testsuite used to check the correctness of rustc C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Milestone
old 1.0 milestone
Development

No branches or pull requests
2 participants
@graydon @brson