This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: new DWARF-2 reader


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]