This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: PATCH: new DWARF-2 reader
- From: Casey Marshall <csm at gnu dot org>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: java-patches at gcc dot gnu dot org
- Date: Fri, 01 Apr 2005 11:36:59 -0800
- Subject: Re: PATCH: new DWARF-2 reader
- References: <1112370111.6008.10.camel@dang5.watson.ibm.com>
>>>>> "Daniel" == Daniel Berlin <dberlin@dberlin.org> writes:
Daniel> This won't thread properly, sorry (i'm not on the list, so this is a
Daniel> paste from the web archives)
>> >>>>> "Casey" == Casey Marshall <csm@gnu.org> writes:
>>
>> Revised again, fixing a few remaining problems with the
>> implementation (the DWARF-2 spec is really hard to interpret! I
>> hope now that it is accurate) and fit it into the Throwable
>> machinery.
>>
>>
Daniel> You should look at the DWARF-3 spec on dwarf.freestandards.org
Daniel> A lot of stuff has been clarified.
Indeed, it has been. Thanks for the pointer, I couldn't find many
resources that weren't terrificly out of date.
Daniel> On that note:
>> +
>> + private void get (ByteBuffer b)
>> + {
>> + total_length = (long) b.getInt () & 0xFFFFFFFFL;
>>
Daniel> If total_length == 0xfffffff,
Daniel> then the offset size is 8 (IE it's a 64 bit value)
Daniel> This is how dwarf-3 differentiates between 32 bit and 64 bit sections.
Daniel> This is *actually used* in practice, so it shoudl be handled.
I see; that should be easy to handle.
>> + version = b.getShort () & 0xFFFF;
>> + prologue_length = (long) b.getInt () & 0xFFFFFFFFL;
Daniel> ^^^^^^^^^^^^^^
Daniel> This field is offset_size bytes
Ok.
>> + minimum_instruction_length = b.get () & 0xFF;
>> + default_is_stmt = b.get () != 0;
>> + line_base = b.get ();
>> + line_range = b.get () & 0xFF;
>> + opcode_base = b.get () & 0xFF;
>> + b.get (standard_opcode_lengths);
>> + }
>> +
>> + if (header.version != 2 || header.opcode_base != 10)
>>
Daniel> version == 3 is in use now as well.
Daniel> Why not support opcode_base other than 10 as well?
Daniel> It's just a little more code for standard opcode lengths.
Yeah, it should handle version 3 and different opcode_base values.
>> + final int const_pc_add = 245 / header.line_range;
>>
Daniel> It's actually ((255 - opcode_base) / (line_range) * min_insn_length)
Ok. This was probably just my optimization of assuming both the
opcode_base was 10 and that min_insn_length was 1.
Thanks for the feedback!
--
Casey Marshall || csm@gnu.org