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

[Jesper Antonsson via llvm-dev]

Hi Simon,

It's encouraging that there are others in the same situation that have
been developing similar solutions. I agree this really makes the case
for having a solution in-tree. I just watched your Fosdem video and
indeed we seem to have very similar solutions with DataLayout and so
on, although we have been sticking with the "byte" vocabulary. (As the
standard does not peg it to 8 bits, I think there'd be some
disadvantages to honoring a faulty assumption.)

As you guys seem to be preparing to move on this by introducing an in-
tree target, I guess we at Ericsson should rest for now. We'll be happy
to assist in any way, though, for instance by reviewing code. Please
let us know if there's anything we can do and let's keep in touch!

Thanks, Jesper


On lör, 2017-02-04 at 13:52 +0000, Simon Cook wrote:
> 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
> >