History log of /dalvik/dx/src/com/android/dx/dex/file/DebugInfoEncoder.java
Revision Date Author Comments
333201833d506a3accdeac6ceb7caba8d4b95797 13-Apr-2011 Jesse Wilson <jessewilson@google.com> Combine CstUtf8 and CstString.

The only benefit we were seeing is that one wrapped its toHuman
in quotes, the other didn't.

It was far too easy to use the wrong one. We had code defending
against that in NameValuePair and CstArray.

Change-Id: Ib2e6a1596b97decced37952d46e1831b7bcd0d5d
dfc5e8e159e7df3efa47d553b7725be22839665d 14-Jan-2011 Jesse Wilson <jessewilson@google.com> Read Dex files from a byte[] rather than a RandomAccessFile.

This improves time to merge a trivial file with core.dex from
3.8 seconds to 0.8 seconds.

Also fixing read method names to be consistent with the spec.

Change-Id: I9033bcb497afe7a0d73e00cca14fa046b53a62bf
72e93344b4d1ffc71e9c832ec23de0657e5b04a5 13-Nov-2009 Jean-Baptiste Queru <jbq@google.com> eclair snapshot
f58a5f30d1f0613e9e2dd3a24e6057f970258dae 09-Jun-2009 Dan Bornstein <danfuzz@android.com> At least mostly-fix internal issue #1898095 / public issue #2868.

The problem is that Scala code may have two variables with the same
name that are simultaneously active, and dx didn't expect that ever to
be the case. The fix is simply to catch another case where a local
variable might be considered to become superfluous due to having an
empty extent. However, this is really more of a workaround, as the
result will be that such code when attached to a debugger will only
show one of the two (or more) same-named variables as being active at
any given time.

The thing that prevents a more satisfactory solution is that the
optimization code can end up "splitting up" a single local into
multiple registers, and the only way we have to track them is by
name/type. So, even without Scala's rules, it was already possible to
find a same-named local in multiple registers, but with the status
quo, finding that really meant that a local was moving from one
register to another. The local variable table code handles that case
by automatically "ending" variables that appear to move, and the Scala
case looks just like that.

In the long run, we probably want to have a way to tag local variables
that isn't just name/type, but that will have to come later.

(As a bonus, I did some minor renaming for clarity while I was in the
territory.)
ac5e0e7a30c3a086f5f07f99cd02ef9943356e0c 04-Jun-2009 Ben Gruver <jesusfreke@jesusfreke.com> dx incorrectly writes registers as a signed leb128 in the dex debug info

This has no functional effect, because reading the signed leb128 value
as an unsignedleb128 still produces the same value. But the encoding is
1 byte longer in some cases.
41aecd0a6bfea1e9a6713014b2b3d56fec8c552c 04-May-2009 Dan Bornstein <danfuzz@android.com> Tweaks, Mostly grep-based, to better conform to the coding guidelines.
99409883d9c4c0ffb49b070ce307bb33a9dfe9f1 19-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import //branches/master/...@140412
f6c387128427e121477c1b32ad35cdcaa5101ba3 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
f72d5de56a522ac3be03873bdde26f23a5eeeb3c 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
31e30105703263782efd450d356cd67ea01af3b7 03-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@132589
6dcac3deb3c19dc634470eb30b2daedf2b201bd4 03-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@137055
446b11cd80658706d77d58996670b8eead3683a4 13-Feb-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //branches/cupcake/...@131421
2ad60cfc28e14ee8f0bb038720836a4696c478ad 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution