{"action":"created","issue":{"url":"https://api.github.com/repos/softdevteam/ykstackmaps/issues/2","repository_url":"https://api.github.com/repos/softdevteam/ykstackmaps","labels_url":"https://api.github.com/repos/softdevteam/ykstackmaps/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/softdevteam/ykstackmaps/issues/2/comments","events_url":"https://api.github.com/repos/softdevteam/ykstackmaps/issues/2/events","html_url":"https://github.com/softdevteam/ykstackmaps/issues/2","id":338270650,"node_id":"MDU6SXNzdWUzMzgyNzA2NTA=","number":2,"title":"ykstackmaps can't deal with >1 compilation unit","user":{"login":"vext01","id":604955,"node_id":"MDQ6VXNlcjYwNDk1NQ==","avatar_url":"https://avatars2.githubusercontent.com/u/604955?v=4","gravatar_id":"","url":"https://api.github.com/users/vext01","html_url":"https://github.com/vext01","followers_url":"https://api.github.com/users/vext01/followers","following_url":"https://api.github.com/users/vext01/following{/other_user}","gists_url":"https://api.github.com/users/vext01/gists{/gist_id}","starred_url":"https://api.github.com/users/vext01/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vext01/subscriptions","organizations_url":"https://api.github.com/users/vext01/orgs","repos_url":"https://api.github.com/users/vext01/repos","events_url":"https://api.github.com/users/vext01/events{/privacy}","received_events_url":"https://api.github.com/users/vext01/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-07-04T13:11:55Z","updated_at":"2018-07-04T13:15:55Z","closed_at":null,"author_association":"MEMBER","body":"Currently ykstackmaps finds the stackmap section, and reads the stackmap info it finds there, allowing the user to iterate it, stopping after the end of all stackmap records.\r\n\r\nThe problem is that multiple stackmap \"tables\" can be encoded in the section. If you have more than one CGU, then multiple sets of stackmap info are created independently in separate object files. Then at the end, the linker simply concatenates all of the stackmap infos together back-to-back (using the documented 8-byte alignment on the end of each stackmap \"block\").\r\n\r\nykstackmaps only expects one \"table\" of stackmap info, but there can be many.\r\n\r\nYou can verify this using radare2.\r\n\r\n```\r\n$ r2 mybin # assume >1 CGU was used\r\n[0x00022e90]> f | grep LLVM_Stack   \r\n0x000f2f50 0 loc.__LLVM_StackMaps   \r\n0x000f3008 0 loc.__LLVM_StackMaps_1 \r\n0x000f3078 0 loc.__LLVM_StackMaps_2 \r\n0x000f30b8 0 loc.__LLVM_StackMaps_3 \r\n0x000f3248 0 loc.__LLVM_StackMaps_4 \r\n0x00116568 0 loc.__LLVM_StackMaps_5 \r\n0x001343e0 0 loc.__LLVM_StackMaps_6 \r\n0x0014adb8 0 loc.__LLVM_StackMaps_7\r\n...\r\n[0x000f2f50]> s loc.__LLVM_StackMaps\r\n[0x000f2f50]> px\r\n- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF\r\n0x000f2f50  0300 0000 0200 0000 0000 0000 0500 0000  ................\r\n0x000f2f60  c02f 0200 0000 0000 4800 0000 0000 0000  ./......H.......\r\n[0x00000000]> s loc.__LLVM_StackMaps_1\r\n[0x000f3008]> px\r\n- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF\r\n0x000f3008  0300 0000 0100 0000 0000 0000 0300 0000  ................\r\n0x000f3018  5030 0200 0000 0000 7800 0000 0000 0000  P0......x.......\r\n```\r\n\r\nWe can see in the hexdumps above the stackmap version, # of funcs, # of constants and # of records fields for those two stackmap \"tables\".\r\n\r\nUltimately, we'd want to allow >1 CGU, which would mean finding a way to know how many tables to expect and reading them all.\r\n\r\nUntil then, we can use the following hack to force one CGU and thus one set of stackmap data. In `Cargo.toml`:\r\n```\r\n[profile.dev]                                                                   \r\ncodegen-units = 1                                                               \r\nincremental = false       \r\n```\r\n\r\n(`profile.release` for `--release` builds)\r\n\r\nThis seems to give a full set of stackmaps in the first table, BUT sadly r2 still finds other tables (`loc.__LLVM_StackMaps_1` etc.) which contain garbage. The have a correct looking LLVM stackmap version header, but the info beyond that is junk.\r\n\r\nWe'd need to look into a way to find how many tables to look for.\r\n"},"comment":{"url":"https://api.github.com/repos/softdevteam/ykstackmaps/issues/comments/402476131","html_url":"https://github.com/softdevteam/ykstackmaps/issues/2#issuecomment-402476131","issue_url":"https://api.github.com/repos/softdevteam/ykstackmaps/issues/2","id":402476131,"node_id":"MDEyOklzc3VlQ29tbWVudDQwMjQ3NjEzMQ==","user":{"login":"vext01","id":604955,"node_id":"MDQ6VXNlcjYwNDk1NQ==","avatar_url":"https://avatars2.githubusercontent.com/u/604955?v=4","gravatar_id":"","url":"https://api.github.com/users/vext01","html_url":"https://github.com/vext01","followers_url":"https://api.github.com/users/vext01/followers","following_url":"https://api.github.com/users/vext01/following{/other_user}","gists_url":"https://api.github.com/users/vext01/gists{/gist_id}","starred_url":"https://api.github.com/users/vext01/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vext01/subscriptions","organizations_url":"https://api.github.com/users/vext01/orgs","repos_url":"https://api.github.com/users/vext01/repos","events_url":"https://api.github.com/users/vext01/events{/privacy}","received_events_url":"https://api.github.com/users/vext01/received_events","type":"User","site_admin":false},"created_at":"2018-07-04T13:15:55Z","updated_at":"2018-07-04T13:15:55Z","author_association":"MEMBER","body":"There's another side-problem relating to your question too. To correctly issue sequential stackmap IDs we cannot use incremental compilation either. Since we are forking rustc, we can pretty do what we want, so yes, we could check for these things."}}
{"actor":{"display_login":"vext01"}}