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

Jump to bottom

Incorrect debug info for calls to printf #7790

Closed
vicuna opened this issue May 3, 2018 · 3 comments
Closed

Incorrect debug info for calls to printf #7790

vicuna opened this issue May 3, 2018 · 3 comments
Labels
back-end bug

Comments

@vicuna
Copy link

vicuna commented May 3, 2018

Original bug ID: 7790
Reporter: alexSanchezStern
Status: resolved (set by @xavierleroy on 2018-05-06T08:18:31Z)
Resolution: fixed
Priority: normal
Severity: minor
Platform: Linux
OS: Gentoo Linux
OS Version: 4.12.12-gentoo
Version: 4.04.2
Fixed in version: 4.05.0
Category: back end (clambda to assembly)

Bug description

When calls are made to Printf.printf, the generated debug info in native code assembly marks the call instruction as coming from the callee, printf, not the caller as it should be.

Steps to reproduce

  1. Compile the following program as hello-world.ml with ocamlopt -g
let say_hello _ =
  let rand = Random.float(1.0) in
  let x = sqrt(rand) in
  Printf.printf "Hello world %e!\n" x;;

say_hello () ;;
  1. Run objdump -d on the binary and search for the say_hello function
  2. Get the address of its call to camlPrintf__fprintf
  3. Run gdb on the binary
  4. Ask for the debug info of the printf call line (in my case info line *0x41c482)
  5. This will return "Line 29 of printf.ml" when the call actually happens at Line 4 of hello_world.ml
@vicuna
Copy link
Author

vicuna commented May 4, 2018

Comment author: @gasche

Isn't this just inlining? printf is defined as a one-line wrapper around fprintf (in printf.ml), so fprintf, if it ends up in the function body by inlining, has debug information located in printf.ml.

@vicuna
Copy link
Author

vicuna commented May 6, 2018

Comment author: @xavierleroy

Printf.printf is inlined at point of call, into some small computations and a call to Printf.fprintf. The call to fprintf (notice the "f" !) is marked as coming from the printf.ml file of the standard library because this is where it occurs initially. So, nothing is wrong here.

@vicuna
Copy link
Author

vicuna commented May 6, 2018

Comment author: @xavierleroy

In private e-mail to me the reporter also noticed that the addsd and subsd instructions corresponding to the occurrences of "+." and "-." in the source code are marked as belonging to random.ml from the standard library.

Here we have a partial inlining (of Random.float) like in the Printf.printf case, but it is true that ocamlopt 4.04.2 does not insert the required ".loc" directive at the end of the inlined code for Random.float, hence a couple of subsequent instructions end up covered by a ".loc" pointing into random.ml

However this bug is seen in 4.04.2 but not in 4.05.0. I'm too lazy to chase the commit that improved the situation. Instead I'll just mark this PR as resolved.

@vicuna vicuna closed this as completed May 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
back-end bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@vicuna