[LLVMdev] FW: IntervalMap - maximum alignment requirements

James Molloy james.molloy at arm.com
Fri Mar 23 00:50:04 PDT 2012


Hi,

 

Bumping this as it appears to have been caught up in the general melee of
mailing list outageness.

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of James Molloy
Sent: 21 March 2012 18:21
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] IntervalMap - maximum alignment requirements

 

Hi,

 

I'm debugging a fault seen in RuntimeDyldELF on 32-bit machines, stemming
from its use of IntervalMap.

 

The documentation at the top of IntervalMap.h states that it is useful for 4
or 8 byte types, and so RuntimeDyldELF correctly uses it. However, further
down the file is this comment:

 

  // The root data is either a RootLeaf or a RootBranchData instance.

  // We can't put them in a union since C++03 doesn't allow non-trivial

  // constructors in unions.

  // Instead, we use a char array with pointer alignment. The alignment is

  // ensured by the allocator member in the class, but still verified in the

  // constructor. We don't support keys or values that are more aligned than
a

  // pointer.

 

Emphasis mine. So my question is, is IntervalMap supposed to support values
greater than the native pointer width, such as uint64_t on a 32-bit system?

 

Should the documentation be updated to reflect this requirement (and
RuntimeDyldELF rewritten to follow it) or should we fix IntervalMap? (my
current hack fix is to add __attribute__((aligned)) to the end of the
'data[]' member, but I'm sure that's not the best way).

 

Cheers,

 

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120323/52967ca2/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001..txt
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120323/52967ca2/attachment.txt>


More information about the llvm-dev mailing list