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

[WIP] Move Ptrace{Request, Event, Options} into enums and bitflags. #461

Closed
wants to merge 1 commit into from

Conversation

chaosagent
Copy link
Contributor

@chaosagent chaosagent commented Nov 6, 2016

Addresses #439.

This is a breaking change.

Currently, PTRACE_EVENTs aren't defined in libc, so they are hardcoded here.

  • OSX support
  • fix i686/arm

@chaosagent
Copy link
Contributor Author

chaosagent commented Nov 6, 2016

The ptrace ffi is included in libc now; should I make a new pull request to change that or do it here?

The ptrace_request argument in lib seems to be c_uint, so some function signatures will need to be changed.

@chaosagent
Copy link
Contributor Author

We could export all the constants and use something like a IntoPtraceRequest trait to keep backwards compatibility, but that would be a bit confusing...

@chaosagent chaosagent changed the title Move Ptrace{Request, Event, Options} into enums and bitflags. [WIP] Move Ptrace{Request, Event, Options} into enums and bitflags. Nov 6, 2016
Copy link
Contributor

@fiveop fiveop left a comment

Choose a reason for hiding this comment

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

Thank you for this PR (and your enthusiasm, given the other issues and PRs).

I left two comments with requests for change (or counter arguments!).

impl PtraceEvent {
/// Creates a PtraceEvent from the extra bits of a wait status (status >> 16)
#[inline]
pub fn from_c_int(event: libc::c_uint) -> Option<PtraceEvent> {
Copy link
Contributor

Choose a reason for hiding this comment

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

for ::nix::sys::signal::Signal we used Result<Signal> as a return type for the corresponding function. I think this is better, because I don't think anyone would intentionally put a wrong c_uint into from_c_int, so the None return type is never expected, thus should probably be an error type.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah sounds good I'll change that soon

#[cfg(any(target_os = "linux", target_os = "android"))]
#[derive(Eq, PartialEq, Clone, Copy, Debug)]
#[repr(u32)]
pub enum PtraceEvent {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should use #[repr(i32)] and thus consistently the type, which is used by the ffi function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't actually need the ffi function anymore, as ptrace has been added to the libc crate (https://doc.rust-lang.org/time/libc/fn.ptrace.html). u32 is consistent with libc's use of c_uint, but not with most C compilers' usage of int for enums (its not defined in the C spec afaik).

I feel like the cleanest way to do this is to remove nix's ffi and just wrap libc as it is and leave the rest up to libc upstream. Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

In general, we do defer to libc. I just think that the signatures of libc::ptrace und from_c_[u]int should use the same type (either c_int or c_uint), depending on libc::ptrace, because we have no influence on it.

@Susurrus
Copy link
Contributor

Susurrus commented Jun 2, 2017

Any willingness to push this over the finish line @chaosagent? This came up again because of #614. I'd love to get the ptrace module a little more cleaned up.

@Susurrus
Copy link
Contributor

@chaosagent Just wanted to ping you again on this as I'd really like to clean up our ptrace API. Would you be able to clean this up anytime in the near future?

@Susurrus
Copy link
Contributor

Susurrus commented Nov 5, 2017

This was closed by #749.

@Susurrus Susurrus closed this Nov 5, 2017
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.

3 participants