<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I understand. Thank you very much for the thorough explanation, Jim! 🙂<div class=""><br class=""></div><div class=""><br class=""></div><div class="">― Vangelis</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 30 Apr 2020, at 23:38, Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br class="" style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><blockquote type="cite" class="" style="font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="">On Apr 30, 2020, at 12:43 PM, Vangelis Tsiatsianas via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Thank you for the answer, Greg.<div class=""><br class=""></div><div class="">I personally managed to work around the problem, although it confused me a bit at first and took a while to figure out the cause. May I suggest the addition of a note in the documentation of<span class="Apple-converted-space"> </span><font face="SFMono-Regular" class="">"{Breakpoint, Watchpoint}::{Invoke, Set}Callback()"</font> and possibly other relevant functions as a warning to future developers that may stumble upon the same issue?<br class=""><div class=""><br class=""></div><div class="">Regarding the public C++ API, would defining <span class="" style="caret-color: rgb(0, 0, 0); font-family: SFMono-Regular;">"break_id_t"</span> as <span class="" style="caret-color: rgb(0, 0, 0); font-family: SFMono-Regular;">"int64_t"</span> be a viable solution or that change would also break the API? It seems that making both types 64-bit alleviates the issue, despite the sign difference.</div></div></div></div></blockquote><div style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Mangled names don’t encode typedef names, but the bare type. For instance:</div><div style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""> > cat signatures.cpp <br class="">#include <stdint.h><br class="">#include <stdio.h><br class=""><br class="">typedef int64_t break_id_t;<br class=""><br class="">struct Foo {<br class=""> void GiveMeABreak(break_id_t id) { printf("Got: %d\n", id); }<br class="">};<br class=""><br class="">int<br class="">main()<br class="">{<br class=""> Foo myFoo;<br class=""> myFoo.GiveMeABreak(100);<br class=""> return 0;<br class="">}<br class=""> > clang++ -g -O0 signatures.cpp<br class=""> > nm a.out | grep GiveMeABreak<br class="">0000000100000f50 T __ZN3Foo12GiveMeABreakEx<br class=""> > c++filt __ZN3Foo12GiveMeABreakEx<br class="">Foo::GiveMeABreak(long long)<br class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">So this change would change the mangled names of any methods taking a break_id_t, and mean old clients would get missing symbol errors when running with the new API’s. So this isn’t something we can do.</div><div style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Jim</div><div style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><br class="" style="caret-color: rgb(0, 0, 0); font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><blockquote type="cite" class="" style="font-family: SFProText-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">― Vangelis</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 30 Apr 2020, at 22:22, Greg Clayton <<a href="mailto:clayborg@gmail.com" class="">clayborg@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Apr 30, 2020, at 8:50 AM, Vangelis Tsiatsianas via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hello,<div class=""><br class=""></div><div class="">I would like to ask a question regarding<span class="Apple-converted-space"> </span><font face="SFMono-Regular" class="">"BreakpointHitCallback"</font>, which is declared as such:</div><div class=""><br class=""></div><div class=""><font face="SFMono-Regular" class="">bool (*BreakpointHitCallback)(void *baton,<br class=""> StoppointCallbackContext *context,<br class=""> lldb::user_id_t break_id,<br class=""> lldb::user_id_t break_loc_id);</font></div><div class=""><font face="SFProText-Regular" class=""><br class=""></font></div><div class=""><font face="SFProText-Regular" class="">Is there any particular reason that </font><font face="SFMono-Regular" class="">"break_id"</font><font face="SFProText-Regular" class=""><span class="Apple-converted-space"> </span>and </font><font face="SFMono-Regular" class="">"break_loc_id"</font><font face="SFProText-Regular" class=""> are of type "</font><font face="SFMono-Regular" class=""><span class="" style="caret-color: rgb(0, 0, 0);">user_id_t"</span></font><font face="SFProText-Regular" class=""> (64-bit unsigned) instead of<span class="Apple-converted-space"> </span></font><font face="SFMono-Regular" class="">"break_id_t"</font><font face="SFProText-Regular" class=""><span class="Apple-converted-space"> </span>(32-bit signed), which is used both for </font><span class="" style="caret-color: rgb(0, 0, 0); font-family: SFMono-Regular;">"Stoppoint::m_bid"</span><span class="" style="font-family: SFProText-Regular;"> and </span><span class="" style="caret-color: rgb(0, 0, 0); font-family: SFMono-Regular;">"StoppointLocation::m_loc_id"</span><span class="" style="font-family: SFProText-Regular;">?</span></div></div></div></blockquote><div class=""><br class=""></div>I believe this callback predated the time when we added break_id and break_loc_id, and since arguments are part of the signature of C++ functions, we didn't change it in order to keep the public API from changing. Or this could have just been a mistake. Either way, we have a stable API and can't really change it.<br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><font face="SFProText-Regular" class=""><br class=""></font></div><div class="">This causes an issue mainly with internal breakpoints, since the callback of an internal breakpoint with<span class="Apple-converted-space"> </span><font face="SFMono-Regular" class="">(ID == 0xfffffffe)</font><span class="Apple-converted-space"> </span>is called with<span class="Apple-converted-space"> </span><font face="SFMono-Regular" class="">(break_id == 0xfffffffffffffffe)</font>, forcing the callback to cast the argument back to a 32-bit signed in order to use it correctly, e.g. when the IDs are stored and need to be looked up.</div><div class=""><br class=""></div><div class="">A small example attempting to illustrate the problem: <a href="https://godbolt.org/z/y8LbK2" class="">https://godbolt.org/z/y8LbK2</a></div></div></div></blockquote><div class=""><br class=""></div></div>Sorry for the issue, but I think we are stuck with it now.<div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" class="">lldb-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a></div></blockquote></div></blockquote></div><br class=""></div></body></html>