<div dir="ltr">I found <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86RegisterInfo.td?view=markup#l111">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86RegisterInfo.td?view=markup#l111</a><div>
>From line 41 of the same file:</div><div><div>41<span class="" style="white-space:pre"> </span>// Dwarf numbering is different for 32-bit and 64-bit, and there are</div><div>42<span class="" style="white-space:pre"> </span>// variations by target as well. Currently the first entry is for X86-64,</div>
<div>43<span class="" style="white-space:pre"> </span>// second - for EH on X86-32/Darwin and third is 'generic' one (X86-32/Linux</div><div>44<span class="" style="white-space:pre"> </span>// and debug information on X86-32/Darwin)</div>
</div><div><br></div><div>And this link refers to the same issue:</div><div><a href="https://groups.google.com/forum/#!topic/google-breakpad-dev/jhmD18lyKB0">https://groups.google.com/forum/#!topic/google-breakpad-dev/jhmD18lyKB0</a><br>
</div><div><br></div><div>It seems like it's not GCC & DWARF; it's Darwin & Linux...</div><div><br></div><div>So for linux, {gcc, dwarf}_{...}_i386 can be merged into one; nothing else uses them.</div><div>
For OSX, register number will be fetched elsewhere anyway.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 5:08 PM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Ok caught Jason's response after writing that last one.</div><div><br></div><div>What state do you see this in, Jason?<span class="HOEnZb"><font color="#888888"><br>
<br>-Todd</font></span></div><div><br><div class="">On Aug 12, 2014, at 5:05 PM, Todd Fiala <<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>> wrote:<br><br></div></div><div><div class="h5"><blockquote type="cite">
<div><div>Yep, will do later tonight.<br><br>-Todd</div><div><br>On Aug 12, 2014, at 4:32 PM, Tong Shen <<a href="mailto:endlessroad@google.com" target="_blank">endlessroad@google.com</a>> wrote:<br><br></div><blockquote type="cite">
<div><div dir="ltr">Got it. So much magic going on there.<div><br></div><div>+Todd Can you check this in? Thanks!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 4:23 PM, Jason Molenda <span dir="ltr"><<a href="mailto:jmolenda@apple.com" target="_blank">jmolenda@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
> On Aug 12, 2014, at 4:20 PM, Tong Shen <<a href="mailto:endlessroad@google.com" target="_blank">endlessroad@google.com</a>> wrote:<br>
><br>
> There's this line in your dwarfdump output:<br>
> DW_CFA_def_cfa (5 (esp), 4)<br>
> DW_CFA_offset (8 (eip), -4)<br>
><br>
> On Ubuntu 14.04, objdump -W outputs this:<br>
> DW_CFA_def_cfa: r4 (esp) ofs 4<br>
> DW_CFA_offset: r8 (eip) at cfa-4<br>
><br>
> I believe this is the cause. On OSX, esp=5; on linux, esp=4<br>
<br>
<br>
</div></div>Yeah, I was starting to get that impression too. I thought the old esp/ebp mixup was across all the gcc platforms - but who knows. Feel free to fix the RegisterContext_x86 enum definitions for esp/ebp - on Mac OS X we'll still be using the debugserver-provided register definitions. (and we don't use eh_frame very often on Mac OS X - we primarily use a local compact unwind format that I haven't written an importer for yet)<br>
<br>
Normally this kind of thing would be defined in the processor ABI document -- but I've never been able to find a document like that for IA-32.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards, Tong Shen</div>
</div>
</div></blockquote><blockquote type="cite"><div><1.patch></div></blockquote></div></blockquote></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards, Tong Shen</div>
</div>