<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Thanks for bumping and bringing this back to my attention, Arthur.</div><div class=""><br class=""></div><div class="">So the short answer for "how was this ever supposed to work" is "I'm not sure, that was before my time".</div><div class="">However, I think it was originally believed that by not using the extern template instantiations in the library</div><div class="">when the debug mode is enabled (see logic in __config), we would basically be using definitions from the</div><div class="">headers only, which would see the _LIBCPP_DEBUG=X passed by the user, and correctly register whatever</div><div class="">iterators needed to be registered.</div><div class=""><br class=""></div><div class="">I suspect that as time went by and nobody used the feature, support for it declined and eventually things</div><div class="">stopped working sanely. I believe you could probably fix the proximate.pass.cpp test by putting the right</div><div class="">set of functions in the headers (as inlines), and only using the version in the library when the debug mode</div><div class="">isn't in effect. However, that is very brittle IMO.</div><div class=""><br class=""></div><div class="">I also do know there's been some gripes about the debug mode ever since I started getting involved in</div><div class="">libc++, and I also do know that Apple has never shipped the debug mode. And when I say Apple has</div><div class="">never shipped the debug mode, I mean it has never shipped a library that even contained support for</div><div class="">the debug mode - so if you were to try enabling it while linking against the system library, you would</div><div class="">get linker errors like:</div><div class=""><br class=""></div><div class=""><div class=""> Undefined symbols for architecture x86_64:</div><div class=""> "std::__1::__libcpp_db::__find_c_from_i(void*) const"</div></div><div class=""><br class=""></div><div class="">I can't speak for other vendors, but I would assume most have been shipping support for the debug</div><div class="">mode (i.e. the iterator database). However, I strongly suspect no user has ever tried using it seriously</div><div class="">(I would love to hear about it if I'm wrong).</div><div class=""><br class=""></div><div class="">So, to summarize, it looks like we've got a debug mode with a usage story that doesn't work. What do we do?</div><div class="">I see a couple options:</div><div class=""><br class=""></div><div class="">1. We make the debug mode a configure-time setting that vendors can use to control whether the debug mode</div><div class=""> is enabled for the flavor of libc++ that they build. Users can't control that. Then, if a vendor is interested in</div><div class=""> shipping it, they can start shipping a version of the library with the debug mode enabled, and add a nice</div><div class=""> compiler option that causes Clang to link against the debug-enabled libc++ instead of the normal libc++.</div><div class=""> Or something along those lines.</div><div class=""><br class=""></div><div class="">2. We try to tweak the debug mode with the current usage model such that it passes our test suite. As Arthur</div><div class=""> nicely explained though, that means we'll be walking in a minefield since any function compiled into the library</div><div class=""> will not be registering its iterators, so if they leak anywhere where the debug mode is enabled, BOOM. CI might</div><div class=""> be enough to catch this, but that sounds brittle to me.</div><div class=""><br class=""></div><div class="">3. Eric Fiselier (CC'd) had once told me about a debug mode design he'd thought about based on ASAN (I think) that</div><div class=""> did not require a separate build of the library. This might be a viable path forward too, and we could investigate it</div><div class=""> if we have more information.</div><div class=""><br class=""></div><div class="">4. We rip out support for the debug mode entirely since it has very few serious users (I know of some, but not many).</div><div class=""><br class=""></div><div class="">Personally, I think having a debug mode is something useful, so I would rather see us fix it than get rid of it.</div><div class="">Unless someone else can provide additional context around how the debug mode was originally supposed to</div><div class="">work, I would strongly go for (1) or (3), but not (2). Solutions (1) and (3) are the ones that will empower vendors</div><div class="">to do what's right for their users most easily, at least from my perspective. If we go for (2), unless I misunderstand</div><div class="">something fundamental, I don't think we'll ever be able to get the debug mode to a point where it is sufficiently solid</div><div class="">so that vendors are able to ship it.</div><div class=""><br class=""></div><div class="">If we go for (1), I can lay out the steps to get us there (and do some of them). I've already thought about it some.</div><div class="">Eric, do you have an opinion? Would you like to expand on (3)?</div><div class=""><br class=""></div><div class="">Louis</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 9, 2021, at 10:24, Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com" class="">arthur.j.odwyer@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Bump again, since this just came up AGAIN in Louis's <a href="https://reviews.llvm.org/D103960" class="">https://reviews.llvm.org/D103960</a></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 29, 2021 at 1:00 PM Mark de Wever <<a href="mailto:koraq@xs4all.nl" class="">koraq@xs4all.nl</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, May 08, 2021 at 04:49:20PM -0400, Arthur O'Dwyer via libcxx-dev wrote:<br class="">
> Gentle bump.<br class="">
><br class="">
> Quoting myself for emphasis:<br class="">
> ><br class="">
> > The problem seems to be that<br class="">
> > (1) libc++.a needs to copy strings sometimes, so it contains codegen for<br class="">
> the copy constructor<br class="">
> > (2) libc++.a is compiled with -D_LIBCPP_DEBUG=0, i.e., assertions but no<br class="">
> debug iterators<br class="">
> > (3) Therefore any strings created by the copy constructor inside<br class="">
> libc++.a, don't get registered with the debug-iterators library<br class="">
> > (4) Therefore pretty much everything is affected by unpredictable<br class="">
> assert-fails??<br class="">
> ><br class="">
> > The real question is, how was this ever *supposed* to work?<br class="">
<br class="">
It seems the issue also happens with strings returned from<br class="">
std::to_string. This function is implemented in src/string.cpp.<br class="">
I ran into it a while ago while implementing the std::formatter stubs.<br class="">
<br class="">
(I actually forgot about this issue, but Arthur reminded me.)<br class="">
<br class="">
To me it seems unintentional and unwanted. But I don't have a suggestion<br class="">
how to fix it.<br class="">
<br class="">
Cheers,<br class="">
Mark de Wever<br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>