Hans,
You can find some complete walks in lldb for the failing
boehm-gc test cases on darwin15 attached to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 as well as
stand-alone binaries for reproducing their failure on
x86_64-apple-darwin15 (should you have access to a Mac running El
Capitan). The developers at Apple identified...
http://llvm.org/viewvc/llvm-project?view=revision&revision=226751
as the change in llvm which sensitized Apple's libunwind.dylib to the
apparently latent boehm-gc bug. My limited understanding of the bug is
that the latent bug is a 16-bit alignment issue being exposed on
darwin since the failing test cases seem to go through...
libdyld.dylib`stack_not_16_byte_aligned_error
during the walks in lldb. I assumed that the use of ALIGNMENT 2 was
forcing the 16-bit alignment and suppressing the bug in current gcc's
boehm-gc.
Jack
On Fri, Jan 1, 2016 at 1:28 PM, Hans Boehm <bo...@acm.org> wrote:
> [Adding Ivan, the current bdwgc maintainer.]
>
> I don't fully understand the issue here. Do we understand where the problem
> is coming from? Are the compiler/linker generating misaligned pointers
> someplace? That would strike me as a misfeature elsewhere.
>
> Setting ALIGNMENT to 2, as in the patch, is a pretty big hammer. It causes
> the gc to look for pointers at every 2 byte offset, quadrupling the number
> of potential pointers that are tested, and significantly increasing the risk
> of finding "false" pointers. I would expect more problems caused by large
> block allocations.
>
> Hans
>
> On Mon, Dec 28, 2015 at 1:44 PM, Mike Stump <mikest...@comcast.net> wrote:
>>
>> On Dec 22, 2015, at 9:08 AM, Jack Howarth <howarth.at....@gmail.com>
>> wrote:
>> > This bug doesn't exist in the more recent boehm-gc 7.2 or
>> > later releases. Until the exact change from 6.6 to 7.2 that suppresses
>> > this bug is identified or FSF gcc's boehm-gc is rebased on the 7.2
>> > version or later, the simple fix to suppress this issue on darwin is
>> > to enforce 16-bit alignment in boehm-gc/include/private/gcconfig.h for
>> > that target.
>>
>> It would be nice to just pull in 7.2 (or just the latest release)… seems
>> like that should be easier to maintain to me.
>>
>> > Okay for gcc trunk and back ports to gcc-5-branch and gcc-4_9-branch?
>>
>> I’d like to punt the approval to a libboehm person, though, not sure we
>> have any. Just checked we don’t have an official maintainer listed. :-(
>> Do we have anybody that wants to review the patch or should I? Though I
>> would prefer a new import of a newer library to fix the issue, I’m tempted
>> to just approve the patch. Kinda don’t want to as any deviation makes
>> importing a new library annoying. What do others think?
>
>
