On Tue, Nov 6, 2012 at 5:11 AM, Eli Bendersky <span dir="ltr"><<a href="mailto:eliben@google.com" target="_blank">eliben@google.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> In place of applying the relocations to the data we've read from disk I'm<br>
> keeping a separate mapping table to the side and checking that at locations<br>
> in the dwarf I'm expecting relocated values. This adds a bit of complexity<br>
> to the dwarf parsing/extraction at the benefit of not allocating memory for<br>
> the entire size of the debug info section.<br>
><br>
<br>
</div>A slightly expanded version of this will make for a great comment in<br>
the code :-) Seriously, please document the purpose of the new<br>
relocMap data structure you're adding.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Uh hey, good point. Done :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> Couple of areas that will need to be improved later:<br>
><br>
> a) Relocations in more than a single section: the .debug_info section is the<br>
> primary one I cared about first, however, we'll need either<br>
>   1) A better mapping that contains section + address (since the debug<br>
> sections are mapped at address 0 I can't just use total offset)<br>
>   2) More mappings per section we're disassembling<br>
><br>
> I'm likely to go with #2 rather than #1, but I'm open to any rationale<br>
> either direction.<br>
><br>
<br>
</div>I'm not sure I understood #2 - can you elaborate?<br></blockquote><div><br></div><div>Yeah, it'll look like this:</div><div><div>  static DIContext *getDWARFContext(bool isLittleEndian,</div><div>                                    StringRef infoSection,</div>
<div>                                    StringRef abbrevSection,</div><div>                                    StringRef aRangeSection = StringRef(),</div><div>                                    StringRef lineSection = StringRef(),</div>
<div>                                    StringRef stringSection = StringRef(),</div><div>                                    StringRef rangeSection = StringRef(),</div><div>                                    const RelocAddrMap &infoSectionMap = RelocAddrMap(),</div>
<div>                                    const RelocAddrMap &aRangeSectionMap = RelocAddrMap(),</div><div>                                    const RelocAddrMap &lineSectionMap = RelocAddrMap());</div></div><div><br>
</div><div>instead of:</div><div><br></div><div><div>  static DIContext *getDWARFContext(bool isLittleEndian,</div><div>                                    StringRef infoSection,</div><div>                                    StringRef abbrevSection,</div>
<div>                                    StringRef aRangeSection = StringRef(),</div><div>                                    StringRef lineSection = StringRef(),</div><div>                                    StringRef stringSection = StringRef(),</div>
<div>                                    StringRef rangeSection = StringRef(),</div><div>                                    const RelocAddrMap &Map = RelocAddrMap());</div></div><div><br></div><div>where I add a section specific map. It's more variables to a constructor and a bit more to look up, but more obvious what's going on. There's some complexity in deciding which is the proper map to grab at the right time, but that can be done as we go through the sections without needing to change the form parser.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> I've got plans to add these things as I go along, but since it was now<br>
> pretty usable for testing/dumping I wanted to get it in and then incremental<br>
> on top of it.<br>
<br>
</div>Do you have any tests for this?<br></blockquote><div><br></div><div>I mostly plan on using for writing tests for debug info, I can add a simple one that shows the proper strings and addresses output for a simple testcase though via the existing debug info tests that use dwarfdump and just make one use x86_64-elf. That about what you were thinking about?</div>
<div><br></div><div>Thanks!</div><div><br></div><div>-eric</div><div><br></div><div> </div></div><br></div>