[lldb-dev] Reporting bugs which only affect (semi-proprietary) downstream consumers.

[Adam HARRIES via lldb-dev]

Hi all,

I've recently taken over maintenance of my company's llvm+lldb branch,
where we have added support for our in-house architecture (in llvm) as well
as support for debugging through both hardware and our simulator. Our llvm
fork is public/open source, however many of our runtime libraries and
drivers (which are linked into lldb, clang, etc, and provide built-ins and
driver support etc) are not.

While attempting to update our branch from llvm-11 to llvm-12 we came
across a commit[1] in lldb which quite reliably causes a deadlock when we
launch a process to debug a core dump. Luckily, said commit simply modifies
some concurrency primitives, and reverting it is sufficient to fix the bug
without any further effects. We are quite confident that the commit is the
issue, as we performed a thorough bisect which maintained "our" code
unchanged throughout.

Unfortunately, however, we are unable to reproduce this bug in any "open"
architectures (such as x86-64, AArch64, etc), so are not entirely sure how
we should go about reporting the bug. Additionally, it makes it difficult
to open a discussion regarding whether the commit is correct (and thus we
may need to modify our additions to lldb to match new implicit behaviour),
as third parties may be unable to reproduce the issue. Finally, as the bug
results in a deadlock (which requires a sigkill to end) we won't (as I
understand it) be able to use a "Reproducer" to demonstrate the bug to
third parties.

Although we are able to "solve" the issue locally (by reverting the
commit), we feel that the better solution would be to feed back our
findings to the community and solve the issue, rather than (privately)
sweeping it under the rug. As components of our compiler are proprietary,
however, this process becomes difficult due to the reasons listed above.

To summarise, there are two main questions that I feel unable to answer:
- Is there an existing process for reporting bugs that only affect third
parties, and which cannot be reproduced in "core" targets.
- To what extend is it possible to discuss (or report) bugs "on faith" - as
in without any concrete evidence that a third party can reproduce.

We are currently looking into opening up our build process so that we are
able to distribute binary libraries to enable third parties to build our
compiler + debugger, but as this is currently a work-in-progress it is
unfortunately not a solution to this issue.

Many thanks in advance for any and all advice.
Yours,

-- 
*Adam Brouwers-Harries*
Compiler Engineer
aharries at upmem.com

[1] Please note, I have specifically not named this commit as I wish to
better understand the "meta"-bug filing process, and I do not wish to
publicly assign blame for any bugs without understanding how and why I can
do so respectfully and properly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20210622/7fe7defc/attachment-0001.html>