[llvm-dev] 16-bit bytes for AsmPrinter/DWARF

[Simon Cook via llvm-dev]

Hi Jesper,

We have been trying to solve this problem ourselves for a couple of
out of tree backends, and our solution has involved calculating
everything LLVM in "char" size instead of hard-coded 8-bit (so this
would be 16-bit in this case), and then for AsmPrinter we convert from
chars to octets for the purpose of DWARF generation. I think what
you're describing sounds like a similar approach to this problem.

In the long term we hope to push this upstream, as it seems this is a
problem people re-solve again in various out of tree forks and it
makes sense to have a good solution in-tree which would make
everyones' lives easier. This is one of the things we're hoping to fix
with the AAP backend (we're working on a 16-bit addressibility mode).
My colleague Ed Jones is giving a talk about this tomorrow at FOSDEM
(https://fosdem.org/2017/schedule/event/llvm_16_bit/), and hope to
start a longer discussion about this either at FOSDEM or at EuroLLVM,
and solve this problem for good.

Thanks,
Simon

On Fri, Jan 20, 2017 at 5:21 PM, Jesper Antonsson via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi,
>
>
>
> I’m with a team using 16-bit bytes for an out-of-tree target. The AsmPrinter
> framework’s implementation of the DWARF debugging format is not very good at
> distinguishing between target-sized bytes (which is the more common use) and
> 8-bit-bytes. The DWARF standard itself seems not very good in this regard,
> actually. So we have had to hack our way around this. I.e., at some
> call-sites of EmitSymbolValue(), EmitLabelDifference(), EmitIntValue() and
> EmitLabelReference(), an 8-bit-byte-sized argument has had to be converted
> to target-byte-size (which is extra hacky for odd numbers of
> eight-bit-bytes).
>
>
>
> We’ve been thinking about what a good upstream fix would look like, and
> believe that perhaps converting all Size arguments in these call chains to
> BitSize would be the most practical way. The “cost” would be the
> multiplications necessary at call-sites. Would this be a good suggestion,
> and would anybody like to view and accept our patches for this?
>
>
>
> Thanks,
>
> Jesper
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>