Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007790OCamlback end (clambda to assembly)public2018-05-04 00:432018-05-06 10:18
ReporteralexSanchezStern 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformLinuxOSGentoo LinuxOS Version4.12.12-gentoo
Product Version4.04.2 
Target VersionFixed in Version4.05.0 
Summary0007790: Incorrect debug info for calls to printf
DescriptionWhen 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 Reproduce1. 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 () ;;
```

2. Run `objdump -d` on the binary and search for the `say_hello` function
3. Get the address of its call to camlPrintf__fprintf
4. Run `gdb` on the binary
5. Ask for the debug info of the printf call line (in my case `info line *0x41c482`)
6. This will return "Line 29 of printf.ml" when the call actually happens at Line 4 of hello_world.ml
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0019099)
gasche (administrator)
2018-05-04 07:23

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.
(0019104)
xleroy (administrator)
2018-05-06 10:14

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.
(0019105)
xleroy (administrator)
2018-05-06 10:18

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.

- Issue History
Date Modified Username Field Change
2018-05-04 00:43 alexSanchezStern New Issue
2018-05-04 07:23 gasche Note Added: 0019099
2018-05-06 10:14 xleroy Note Added: 0019104
2018-05-06 10:18 xleroy Note Added: 0019105
2018-05-06 10:18 xleroy Status new => resolved
2018-05-06 10:18 xleroy Resolution open => fixed
2018-05-06 10:18 xleroy Fixed in Version => 4.05.0


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker