[LLVMdev] Win32 COFF Support

[Nathan Jeffords]

On Tue, Sep 28, 2010 at 7:46 PM, Michael Spencer <bigcheesegs at gmail.com>wrote:

> On Tue, Sep 28, 2010 at 7:39 PM, Michael Spencer <bigcheesegs at gmail.com>
> wrote:
> > On Sun, Sep 26, 2010 at 5:27 PM, Nathan Jeffords
> > <blunted2night at gmail.com> wrote:
> >> Hi guys,
> >> While trying to get dwarf debugging information to work with Win32 COFF
> >> targets, I came across a couple of issues with the current
> implementation
> >> of WinCOFFObjectWriter. Emitting empty section causes debug information
> to
> >> invalid, as the presence of certain debug section implies available
> >> information, and emission of labels as symbols confused gdb about the
> >> structure of the program.
> >> The attached patch allows the WinCOFFObjectWriter to drop empty
> sections,
> >> and label symbols. It converts relocations targeted at symbols into
> >> relocations relative to the containing section.
> >> I have not run the tests in the '/test/MC/COFF', but have run through
> the
> >> unit-test framework for my compiler and generated some text executables
> with
> >> clang and everything looks to be in order. It may change the output of
> >> the  '/test/MC/COFF' if the string references are emitted as
> temporaries.
> >> -Nathan
> >
> > http://llvm.org/bugs/show_bug.cgi?id=8248
> >
> > It seems that there actually is a bug. I thought it was due to
> > something else, but reverting this patch fixes it. Why/when exactly
> > does gdb expect IMAGE_SYM_CLASS_LABEL?
> >
> > - Michael Spencer
> >
>
> I've attached a patch that fixes the above problem while keeping the
> LABEL storage class on labels. Can you verify that it keeps the
> behavior you wanted?
>
> - Michael Spencer
>

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.

- Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100928/1336a612/attachment.html>