<div class="gmail_quote">On Tue, Sep 28, 2010 at 7:46 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.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></div><div class="h5">On Tue, Sep 28, 2010 at 7:39 PM, Michael Spencer <<a href="mailto:bigcheesegs@gmail.com">bigcheesegs@gmail.com</a>> wrote:<br>
> On Sun, Sep 26, 2010 at 5:27 PM, Nathan Jeffords<br>
> <<a href="mailto:blunted2night@gmail.com">blunted2night@gmail.com</a>> wrote:<br>
>> Hi guys,<br>
>> While trying to get dwarf debugging information to work with Win32 COFF<br>
>> targets, I came across a couple of issues with the current implementation<br>
>> of WinCOFFObjectWriter. Emitting empty section causes debug information to<br>
>> invalid, as the presence of certain debug section implies available<br>
>> information, and emission of labels as symbols confused gdb about the<br>
>> structure of the program.<br>
>> The attached patch allows the WinCOFFObjectWriter to drop empty sections,<br>
>> and label symbols. It converts relocations targeted at symbols into<br>
>> relocations relative to the containing section.<br>
>> I have not run the tests in the '/test/MC/COFF', but have run through the<br>
>> unit-test framework for my compiler and generated some text executables with<br>
>> clang and everything looks to be in order. It may change the output of<br>
>> the  '/test/MC/COFF' if the string references are emitted as temporaries.<br>
>> -Nathan<br>
><br>
> <a href="http://llvm.org/bugs/show_bug.cgi?id=8248" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=8248</a><br>
><br>
> It seems that there actually is a bug. I thought it was due to<br>
> something else, but reverting this patch fixes it. Why/when exactly<br>
> does gdb expect IMAGE_SYM_CLASS_LABEL?<br>
><br>
> - Michael Spencer<br>
><br>
<br>
</div></div>I've attached a patch that fixes the above problem while keeping the<br>
LABEL storage class on labels. Can you verify that it keeps the<br>
behavior you wanted?<br>
<font color="#888888"><br>
- Michael Spencer<br>
</font></blockquote></div><br><div>That was a mistake on my part. I was trying to figure out why gdb was showing each label as its own function. I tried the label storage class and forgot to revert it. The real fix was not to put temporary symbols into the COFF symbol table. The assignment of the storage class to label in the emit label method is unneeded.<br>
</div><div><br></div><div>- Nathan</div><div><br></div>