llvm dev - Dec 2013 - [LLVMdev] Adding line table debug information to LLVM on Windows

>> >
>>
>> Probably the same structure that we've been going down via
>> lib/DebugInfo/. A set of files than handle reading and parsing and
>> both some binary files and some files produced by the backend.
>
>
> Ooph, that's a big one.
> Any more tips to prioritize diving into this codebase?
>
It mostly uses libObject to do the initial read and parse of the
object file. Past that I'd suggest adding a parallel set of
context/structure like the dwarf one. Ultimately it's going to look
somewhat similar.
>> >> Please see the TODOs in the attached patch.
>> >> You are very likely to come up with a better design/ideas
given I'm
>> >> new to this part of the codebase.
>> >>
>>
>> Will do.
>
>
> Ping?
>
Can you rebase after the other patches and I'll take a more careful look?

-eric
>>
>> >> One particular question I'd like to emphasize is getting a
full
>> >> filepath for a given MDNode.
>> >> As far as I can tell, the metadata for scopes holds pairs of
>> >> <filename, directory>, which reflects how DWARF stores
them.
>> >> However, CodeView stores full paths as entire strings (I admit
that
>> >> ain't efficient).
>> >> Currently, I concat the directory and filename together, but
it
>> >> a) requires some extra memory management
>> >> b) requires special tricks to handle filenames starting from
"./",
>> >> "../", etc.
>> >> c) the slashes in the directory name and filename are not
consistent on
>> >> Windows
>> >> and is ugly in general.
>> >>
>> >> Do you think it's appropriate to change the scope metadata
format to
>> >> store <filename, directory, fullpath> instead?
>> >> That'd require changing Clang, right?
>> >
>>
>> It would require changing clang. Since this is a single string per
>> file I'm not against adding the full path to the source file in the
>> metadata along side the basename/compilation dir pair.
>
>
> OK, will go down this path.
>
>>
>> -eric
>>
>> > ping
>> >
>> >>> -eric
>> >>>
>> >>>
>> >>> On Mon, Nov 18, 2013 at 9:14 AM, Timur Iskhodzhanov
>> >>> <timurrrr at google.com> wrote:
>> >>>> I wrote some more lit tests for my patch and realized
I was
>> >>>> generating
>> >>>> some redundant info. This is fixed now. Attached is a
new version
>> >>>> of the prototype patch with some more tests.
>> >>>>
>> >>>> 2013/11/15 João Matos <ripzonetriton at
gmail.com>:
>> >>>>> Hi Timur,
>> >>>>>
>> >>>>> There's also a pending patch adding CodeView
support in Phab:
>> >>>>> http://llvm-reviews.chandlerc.com/D165
>> >>>>
>> >>>> I haven't looked at your patch yet, but based on
the very low phab
>> >>>> review number, I'm pretty sure there are good
reasons this wasn't
>> >>>> committed.
>> >>>>
>> >>>>> Does your patch provide just a subset of the
CodeView debug info
>> >>>>> provided in
>> >>>>> the other patch?
>> >>>>
>> >>>> Yes. I prefer small incremental changes.
>> >>>> Also, the file:line debug info is much much more
important for me atm
>> >>>> than the other types of debug info.
>> >>>>
>> >>>>> Looking at the patch, I think the approach the
other patch took of
>> >>>>> abstracting the emission of debug information is a
bit cleaner and
>> >>>>> it will
>> >>>>> probably make life easier when adding more debug
formats in the
>> >>>>> future.
>> >>>>
>> >>>> Why wasn't the "abstract the emission of
DI" part of that patch
>> >>>> reviewed/committed separately?
>> >>>>
>> >>>>> On Fri, Nov 15, 2013 at 4:39 PM, Timur
Iskhodzhanov
>> >>>>> <timurrrr at google.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> 2013/11/14 Timur Iskhodzhanov <timurrrr at
google.com>:
>> >>>>>> > Hi David, Eric, LLVM devs,
>> >>>>>> >
>> >>>>>> > You've probably heard about
AddressSanitizer (ASan) and other
>> >>>>>> > sanitizers based on LLVM. One of the
things that makes ASan
>> >>>>>> > not as awesome on Windows as it is on
Linux
>> >>>>>> > is the symbolization of the stacks.
>> >>>>>> >
>> >>>>>> > Currently, ASan runtime on Windows uses
>> >>>>>> >
CaptureStackBackTrace/SymFromAddr/SymGetLineFromAddr64
>> >>>>>> > to unwind and symbolize stacks.  This
works like a charm
>> >>>>>> > in-process for stack frames built with
CL, but yields
>> >>>>>> > "function+0x0ff537" for frames
built with Clang.
>> >>>>>> >
>> >>>>>> > I came up with a prototype which emits
"old-style debug info"
>> >>>>>> > COFF
>> >>>>>> > sections that are sufficient to get
function name / filename /
>> >>>>>> > linenumber information.  That's
pretty much everything that's
>> >>>>>> > required
>> >>>>>> > for ASan to work beautifully in terms of
the completeness of
>> >>>>>> > error
>> >>>>>> > reports.
>> >>>>>> >
>> >>>>>> > Attached is a prototype patch which
I've tried on some simple
>> >>>>>> > tests,
>> >>>>>> > including some more complex ones with
weird #line constructions.
>> >>>>>> > It also works just great on ASan/Win
tests without any
>> >>>>>> > link/run-time
>> >>>>>> > warnings (I had a bunch of those during
development, so I can
>> >>>>>> > tell it
>> >>>>>> > works rather than fails silently).
>> >>>>>> >
>> >>>>>> > I didn't have time to work on
threading the command-line flags
>> >>>>>> > into
>> >>>>>> > the AsmPrinter yet, so currently it just
replaces DWARF entirely.
>> >>>>>> > Of course, this should be fixed before
this lands into trunk.
>> >>>>>> > Currently, one can try this patch by
using "clang-cl -Xclang -g
>> >>>>>> > ...".
>> >>>>>> > Eventually we should have some dedicated
flag for clang-cl.
>> >>>>>> >
>> >>>>>> > Can you please take a look at the patch
and suggest a good path
>> >>>>>> > forward?
>> >>>>>> >
>> >>>>>> > I'm very unfamiliar with LLVM
CodeGen/MC, so I'm pretty sure I
>> >>>>>> > made a
>> >>>>>> > few weird things in the code...  I've
also put a few TODOs with
>> >>>>>> > questions and suggestions.
>> >>>>>> >
>> >>>>>> > Some general questions:
>> >>>>>> > 1) Threading flags from the driver down
to CodeGen.
>> >>>>>> >   How do we do that? Should we support
all 4 combinations
>> >>>>>> >   of no-info/DWARF/CVLT/both?
>> >>>>>> >   How about "-Zmlt" as the
clang-cl flag name? ("minimal line
>> >>>>>> > tables")
>> >>>>>> >
>> >>>>>> > 2) Am I right that DWARF is pretty much
the only debug info
>> >>>>>> > format
>> >>>>>> >   supported by LLVM/AsmPrinter right now?
Do we want to take
>> >>>>>> >   an effort to come up with a generic
debuginfogenerator
>> >>>>>> > interface
>> >>>>>> >   to share between DwarfDebug and
WinCodeViewLineTables?
>> >>>>>> >   Then AsmPrinter should just hold a
>> >>>>>> > SmallVector<DebugInfoEmitter*>
>> >>>>>> >   rather than a pair of DD/DE pointers.
>> >>>>>> >
>> >>>>>> > 3) How would you suggest to write
WinCodeViewLineTables tests
>> >>>>>> >   given that dumpbin is not available
everywhere except Windows?
>> >>>>>> >   // Yeah, I should have looked at the
DwarfDebug LIT tests and
>> >>>>>> >   // written some; but the prototype
development went faster
>> >>>>>> >   // than I expected...
>> >>>>>>
>> >>>>>> I found the MCAsmStreamer being used by llc
which gives a decent
>> >>>>>> text
>> >>>>>> format.
>> >>>>>> I wrote a simple x86+x86_64 .ll test and
FileCheck expectations for
>> >>>>>> the llc asm output.
>> >>>>>> Is this the right approach to write tests?
>> >>>>>> If so, I'll convert my remaining C program
test cases into such an
>> >>>>>> .ll+llc tests.
>> >>>>>>
>> >>>>>> > Can you suggest ways to split this patch
so it's easier
>> >>>>>> > to review part-by-part before this hits
trunk?
>> >>>>>>
>> >>>>>> Attached is an updated patch with a new test
and a few minor things
>> >>>>>> improved.
>> >>>>>> I also removed the "TODO: test on
X64" as I did try it on x64 and
>> >>>>>> no
>> >>>>>> changes were required.
>> >>>>>>
>> >>>>>> Looking forward to your feedback!
>> >>>>>>
>> >>>>>> > Thanks!
>> >>>>>> > --
>> >>>>>> > Timur Iskhodzhanov,
>> >>>>>> > Google
>> >>>>>>
>> >>>>>>
_______________________________________________
>> >>>>>> LLVM Developers mailing list
>> >>>>>> LLVMdev at cs.uiuc.edu        
http://llvm.cs.uiuc.edu
>> >>>>>>
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> João Matos
>
>

2013/12/3 Eric Christopher <echristo at gmail.com>
> >> >
> >>
> >> Probably the same structure that we've been going down via
> >> lib/DebugInfo/. A set of files than handle reading and parsing and
> >> both some binary files and some files produced by the backend.
> >
> >
> > Ooph, that's a big one.
> > Any more tips to prioritize diving into this codebase?
> >
>
> It mostly uses libObject to do the initial read and parse of the
> object file. Past that I'd suggest adding a parallel set of
> context/structure like the dwarf one. Ultimately it's going to look
> somewhat similar.
>
> >> >> Please see the TODOs in the attached patch.
> >> >> You are very likely to come up with a better design/ideas
given I'm
> >> >> new to this part of the codebase.
> >> >>
> >>
> >> Will do.
> >
> >
> > Ping?
> >
>
> Can you rebase after the other patches and I'll take a more careful
look?

Which ones?
It's already rebased on ToT.

 -eric
>
> >>
> >> >> One particular question I'd like to emphasize is
getting a full
> >> >> filepath for a given MDNode.
> >> >> As far as I can tell, the metadata for scopes holds pairs
of
> >> >> <filename, directory>, which reflects how DWARF
stores them.
> >> >> However, CodeView stores full paths as entire strings (I
admit that
> >> >> ain't efficient).
> >> >> Currently, I concat the directory and filename together,
but it
> >> >> a) requires some extra memory management
> >> >> b) requires special tricks to handle filenames starting
from "./",
> >> >> "../", etc.
> >> >> c) the slashes in the directory name and filename are not
consistent
> on
> >> >> Windows
> >> >> and is ugly in general.
> >> >>
> >> >> Do you think it's appropriate to change the scope
metadata format to
> >> >> store <filename, directory, fullpath> instead?
> >> >> That'd require changing Clang, right?
> >> >
> >>
> >> It would require changing clang. Since this is a single string per
> >> file I'm not against adding the full path to the source file
in the
> >> metadata along side the basename/compilation dir pair.
> >
> >
> > OK, will go down this path.
> >
> >>
> >> -eric
> >>
> >> > ping
> >> >
> >> >>> -eric
> >> >>>
> >> >>>
> >> >>> On Mon, Nov 18, 2013 at 9:14 AM, Timur Iskhodzhanov
> >> >>> <timurrrr at google.com> wrote:
> >> >>>> I wrote some more lit tests for my patch and
realized I was
> >> >>>> generating
> >> >>>> some redundant info. This is fixed now. Attached
is a new version
> >> >>>> of the prototype patch with some more tests.
> >> >>>>
> >> >>>> 2013/11/15 João Matos <ripzonetriton at
gmail.com>:
> >> >>>>> Hi Timur,
> >> >>>>>
> >> >>>>> There's also a pending patch adding
CodeView support in Phab:
> >> >>>>> http://llvm-reviews.chandlerc.com/D165
> >> >>>>
> >> >>>> I haven't looked at your patch yet, but based
on the very low phab
> >> >>>> review number, I'm pretty sure there are good
reasons this wasn't
> >> >>>> committed.
> >> >>>>
> >> >>>>> Does your patch provide just a subset of the
CodeView debug info
> >> >>>>> provided in
> >> >>>>> the other patch?
> >> >>>>
> >> >>>> Yes. I prefer small incremental changes.
> >> >>>> Also, the file:line debug info is much much more
important for me
> atm
> >> >>>> than the other types of debug info.
> >> >>>>
> >> >>>>> Looking at the patch, I think the approach
the other patch took of
> >> >>>>> abstracting the emission of debug information
is a bit cleaner and
> >> >>>>> it will
> >> >>>>> probably make life easier when adding more
debug formats in the
> >> >>>>> future.
> >> >>>>
> >> >>>> Why wasn't the "abstract the emission of
DI" part of that patch
> >> >>>> reviewed/committed separately?
> >> >>>>
> >> >>>>> On Fri, Nov 15, 2013 at 4:39 PM, Timur
Iskhodzhanov
> >> >>>>> <timurrrr at google.com>
> >> >>>>> wrote:
> >> >>>>>>
> >> >>>>>> 2013/11/14 Timur Iskhodzhanov
<timurrrr at google.com>:
> >> >>>>>> > Hi David, Eric, LLVM devs,
> >> >>>>>> >
> >> >>>>>> > You've probably heard about
AddressSanitizer (ASan) and other
> >> >>>>>> > sanitizers based on LLVM. One of the
things that makes ASan
> >> >>>>>> > not as awesome on Windows as it is
on Linux
> >> >>>>>> > is the symbolization of the stacks.
> >> >>>>>> >
> >> >>>>>> > Currently, ASan runtime on Windows
uses
> >> >>>>>> >
CaptureStackBackTrace/SymFromAddr/SymGetLineFromAddr64
> >> >>>>>> > to unwind and symbolize stacks. 
This works like a charm
> >> >>>>>> > in-process for stack frames built
with CL, but yields
> >> >>>>>> > "function+0x0ff537" for
frames built with Clang.
> >> >>>>>> >
> >> >>>>>> > I came up with a prototype which
emits "old-style debug info"
> >> >>>>>> > COFF
> >> >>>>>> > sections that are sufficient to get
function name / filename /
> >> >>>>>> > linenumber information.  That's
pretty much everything that's
> >> >>>>>> > required
> >> >>>>>> > for ASan to work beautifully in
terms of the completeness of
> >> >>>>>> > error
> >> >>>>>> > reports.
> >> >>>>>> >
> >> >>>>>> > Attached is a prototype patch which
I've tried on some simple
> >> >>>>>> > tests,
> >> >>>>>> > including some more complex ones
with weird #line
> constructions.
> >> >>>>>> > It also works just great on ASan/Win
tests without any
> >> >>>>>> > link/run-time
> >> >>>>>> > warnings (I had a bunch of those
during development, so I can
> >> >>>>>> > tell it
> >> >>>>>> > works rather than fails silently).
> >> >>>>>> >
> >> >>>>>> > I didn't have time to work on
threading the command-line flags
> >> >>>>>> > into
> >> >>>>>> > the AsmPrinter yet, so currently it
just replaces DWARF
> entirely.
> >> >>>>>> > Of course, this should be fixed
before this lands into trunk.
> >> >>>>>> > Currently, one can try this patch by
using "clang-cl -Xclang -g
> >> >>>>>> > ...".
> >> >>>>>> > Eventually we should have some
dedicated flag for clang-cl.
> >> >>>>>> >
> >> >>>>>> > Can you please take a look at the
patch and suggest a good path
> >> >>>>>> > forward?
> >> >>>>>> >
> >> >>>>>> > I'm very unfamiliar with LLVM
CodeGen/MC, so I'm pretty sure I
> >> >>>>>> > made a
> >> >>>>>> > few weird things in the code... 
I've also put a few TODOs with
> >> >>>>>> > questions and suggestions.
> >> >>>>>> >
> >> >>>>>> > Some general questions:
> >> >>>>>> > 1) Threading flags from the driver
down to CodeGen.
> >> >>>>>> >   How do we do that? Should we
support all 4 combinations
> >> >>>>>> >   of no-info/DWARF/CVLT/both?
> >> >>>>>> >   How about "-Zmlt" as the
clang-cl flag name? ("minimal line
> >> >>>>>> > tables")
> >> >>>>>> >
> >> >>>>>> > 2) Am I right that DWARF is pretty
much the only debug info
> >> >>>>>> > format
> >> >>>>>> >   supported by LLVM/AsmPrinter right
now?  Do we want to take
> >> >>>>>> >   an effort to come up with a
generic debuginfogenerator
> >> >>>>>> > interface
> >> >>>>>> >   to share between DwarfDebug and
WinCodeViewLineTables?
> >> >>>>>> >   Then AsmPrinter should just hold a
> >> >>>>>> > SmallVector<DebugInfoEmitter*>
> >> >>>>>> >   rather than a pair of DD/DE
pointers.
> >> >>>>>> >
> >> >>>>>> > 3) How would you suggest to write
WinCodeViewLineTables tests
> >> >>>>>> >   given that dumpbin is not
available everywhere except
> Windows?
> >> >>>>>> >   // Yeah, I should have looked at
the DwarfDebug LIT tests and
> >> >>>>>> >   // written some; but the prototype
development went faster
> >> >>>>>> >   // than I expected...
> >> >>>>>>
> >> >>>>>> I found the MCAsmStreamer being used by
llc which gives a decent
> >> >>>>>> text
> >> >>>>>> format.
> >> >>>>>> I wrote a simple x86+x86_64 .ll test and
FileCheck expectations
> for
> >> >>>>>> the llc asm output.
> >> >>>>>> Is this the right approach to write
tests?
> >> >>>>>> If so, I'll convert my remaining C
program test cases into such
> an
> >> >>>>>> .ll+llc tests.
> >> >>>>>>
> >> >>>>>> > Can you suggest ways to split this
patch so it's easier
> >> >>>>>> > to review part-by-part before this
hits trunk?
> >> >>>>>>
> >> >>>>>> Attached is an updated patch with a new
test and a few minor
> things
> >> >>>>>> improved.
> >> >>>>>> I also removed the "TODO: test on
X64" as I did try it on x64 and
> >> >>>>>> no
> >> >>>>>> changes were required.
> >> >>>>>>
> >> >>>>>> Looking forward to your feedback!
> >> >>>>>>
> >> >>>>>> > Thanks!
> >> >>>>>> > --
> >> >>>>>> > Timur Iskhodzhanov,
> >> >>>>>> > Google
> >> >>>>>>
> >> >>>>>>
_______________________________________________
> >> >>>>>> LLVM Developers mailing list
> >> >>>>>> LLVMdev at cs.uiuc.edu        
http://llvm.cs.uiuc.edu
> >> >>>>>>
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> João Matos
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131203/bce4a9c2/attachment.html>

On Tue, Dec 3, 2013 at 11:04 AM, Timur Iskhodzhanov <timurrrr at
google.com> wrote:
>
>
>
> 2013/12/3 Eric Christopher <echristo at gmail.com>
>>
>> >> >
>> >>
>> >> Probably the same structure that we've been going down via
>> >> lib/DebugInfo/. A set of files than handle reading and parsing
and
>> >> both some binary files and some files produced by the backend.
>> >
>> >
>> > Ooph, that's a big one.
>> > Any more tips to prioritize diving into this codebase?
>> >
>>
>> It mostly uses libObject to do the initial read and parse of the
>> object file. Past that I'd suggest adding a parallel set of
>> context/structure like the dwarf one. Ultimately it's going to look
>> somewhat similar.
>>
>> >> >> Please see the TODOs in the attached patch.
>> >> >> You are very likely to come up with a better
design/ideas given I'm
>> >> >> new to this part of the codebase.
>> >> >>
>> >>
>> >> Will do.
>> >
>> >
>> > Ping?
>> >
>>
>> Can you rebase after the other patches and I'll take a more careful
look?
>
>
> Which ones?
> It's already rebased on ToT.
>
Thought you had it in phabricator somewhere... if not, where is the
current patch again? :)

-eric


>> -eric
>>
>> >>
>> >> >> One particular question I'd like to emphasize is
getting a full
>> >> >> filepath for a given MDNode.
>> >> >> As far as I can tell, the metadata for scopes holds
pairs of
>> >> >> <filename, directory>, which reflects how DWARF
stores them.
>> >> >> However, CodeView stores full paths as entire strings
(I admit that
>> >> >> ain't efficient).
>> >> >> Currently, I concat the directory and filename
together, but it
>> >> >> a) requires some extra memory management
>> >> >> b) requires special tricks to handle filenames
starting from "./",
>> >> >> "../", etc.
>> >> >> c) the slashes in the directory name and filename are
not consistent
>> >> >> on
>> >> >> Windows
>> >> >> and is ugly in general.
>> >> >>
>> >> >> Do you think it's appropriate to change the scope
metadata format to
>> >> >> store <filename, directory, fullpath> instead?
>> >> >> That'd require changing Clang, right?
>> >> >
>> >>
>> >> It would require changing clang. Since this is a single string
per
>> >> file I'm not against adding the full path to the source
file in the
>> >> metadata along side the basename/compilation dir pair.
>> >
>> >
>> > OK, will go down this path.
>> >
>> >>
>> >> -eric
>> >>
>> >> > ping
>> >> >
>> >> >>> -eric
>> >> >>>
>> >> >>>
>> >> >>> On Mon, Nov 18, 2013 at 9:14 AM, Timur
Iskhodzhanov
>> >> >>> <timurrrr at google.com> wrote:
>> >> >>>> I wrote some more lit tests for my patch and
realized I was
>> >> >>>> generating
>> >> >>>> some redundant info. This is fixed now.
Attached is a new version
>> >> >>>> of the prototype patch with some more tests.
>> >> >>>>
>> >> >>>> 2013/11/15 João Matos <ripzonetriton at
gmail.com>:
>> >> >>>>> Hi Timur,
>> >> >>>>>
>> >> >>>>> There's also a pending patch adding
CodeView support in Phab:
>> >> >>>>> http://llvm-reviews.chandlerc.com/D165
>> >> >>>>
>> >> >>>> I haven't looked at your patch yet, but
based on the very low phab
>> >> >>>> review number, I'm pretty sure there are
good reasons this wasn't
>> >> >>>> committed.
>> >> >>>>
>> >> >>>>> Does your patch provide just a subset of
the CodeView debug info
>> >> >>>>> provided in
>> >> >>>>> the other patch?
>> >> >>>>
>> >> >>>> Yes. I prefer small incremental changes.
>> >> >>>> Also, the file:line debug info is much much
more important for me
>> >> >>>> atm
>> >> >>>> than the other types of debug info.
>> >> >>>>
>> >> >>>>> Looking at the patch, I think the
approach the other patch took
>> >> >>>>> of
>> >> >>>>> abstracting the emission of debug
information is a bit cleaner
>> >> >>>>> and
>> >> >>>>> it will
>> >> >>>>> probably make life easier when adding
more debug formats in the
>> >> >>>>> future.
>> >> >>>>
>> >> >>>> Why wasn't the "abstract the
emission of DI" part of that patch
>> >> >>>> reviewed/committed separately?
>> >> >>>>
>> >> >>>>> On Fri, Nov 15, 2013 at 4:39 PM, Timur
Iskhodzhanov
>> >> >>>>> <timurrrr at google.com>
>> >> >>>>> wrote:
>> >> >>>>>>
>> >> >>>>>> 2013/11/14 Timur Iskhodzhanov
<timurrrr at google.com>:
>> >> >>>>>> > Hi David, Eric, LLVM devs,
>> >> >>>>>> >
>> >> >>>>>> > You've probably heard about
AddressSanitizer (ASan) and other
>> >> >>>>>> > sanitizers based on LLVM. One of
the things that makes ASan
>> >> >>>>>> > not as awesome on Windows as it
is on Linux
>> >> >>>>>> > is the symbolization of the
stacks.
>> >> >>>>>> >
>> >> >>>>>> > Currently, ASan runtime on
Windows uses
>> >> >>>>>> >
CaptureStackBackTrace/SymFromAddr/SymGetLineFromAddr64
>> >> >>>>>> > to unwind and symbolize stacks. 
This works like a charm
>> >> >>>>>> > in-process for stack frames
built with CL, but yields
>> >> >>>>>> > "function+0x0ff537"
for frames built with Clang.
>> >> >>>>>> >
>> >> >>>>>> > I came up with a prototype which
emits "old-style debug info"
>> >> >>>>>> > COFF
>> >> >>>>>> > sections that are sufficient to
get function name / filename /
>> >> >>>>>> > linenumber information. 
That's pretty much everything that's
>> >> >>>>>> > required
>> >> >>>>>> > for ASan to work beautifully in
terms of the completeness of
>> >> >>>>>> > error
>> >> >>>>>> > reports.
>> >> >>>>>> >
>> >> >>>>>> > Attached is a prototype patch
which I've tried on some simple
>> >> >>>>>> > tests,
>> >> >>>>>> > including some more complex ones
with weird #line
>> >> >>>>>> > constructions.
>> >> >>>>>> > It also works just great on
ASan/Win tests without any
>> >> >>>>>> > link/run-time
>> >> >>>>>> > warnings (I had a bunch of those
during development, so I can
>> >> >>>>>> > tell it
>> >> >>>>>> > works rather than fails
silently).
>> >> >>>>>> >
>> >> >>>>>> > I didn't have time to work
on threading the command-line flags
>> >> >>>>>> > into
>> >> >>>>>> > the AsmPrinter yet, so currently
it just replaces DWARF
>> >> >>>>>> > entirely.
>> >> >>>>>> > Of course, this should be fixed
before this lands into trunk.
>> >> >>>>>> > Currently, one can try this
patch by using "clang-cl -Xclang
>> >> >>>>>> > -g
>> >> >>>>>> > ...".
>> >> >>>>>> > Eventually we should have some
dedicated flag for clang-cl.
>> >> >>>>>> >
>> >> >>>>>> > Can you please take a look at
the patch and suggest a good
>> >> >>>>>> > path
>> >> >>>>>> > forward?
>> >> >>>>>> >
>> >> >>>>>> > I'm very unfamiliar with
LLVM CodeGen/MC, so I'm pretty sure I
>> >> >>>>>> > made a
>> >> >>>>>> > few weird things in the code... 
I've also put a few TODOs
>> >> >>>>>> > with
>> >> >>>>>> > questions and suggestions.
>> >> >>>>>> >
>> >> >>>>>> > Some general questions:
>> >> >>>>>> > 1) Threading flags from the
driver down to CodeGen.
>> >> >>>>>> >   How do we do that? Should we
support all 4 combinations
>> >> >>>>>> >   of no-info/DWARF/CVLT/both?
>> >> >>>>>> >   How about "-Zmlt" as
the clang-cl flag name? ("minimal line
>> >> >>>>>> > tables")
>> >> >>>>>> >
>> >> >>>>>> > 2) Am I right that DWARF is
pretty much the only debug info
>> >> >>>>>> > format
>> >> >>>>>> >   supported by LLVM/AsmPrinter
right now?  Do we want to take
>> >> >>>>>> >   an effort to come up with a
generic debuginfogenerator
>> >> >>>>>> > interface
>> >> >>>>>> >   to share between DwarfDebug
and WinCodeViewLineTables?
>> >> >>>>>> >   Then AsmPrinter should just
hold a
>> >> >>>>>> >
SmallVector<DebugInfoEmitter*>
>> >> >>>>>> >   rather than a pair of DD/DE
pointers.
>> >> >>>>>> >
>> >> >>>>>> > 3) How would you suggest to
write WinCodeViewLineTables tests
>> >> >>>>>> >   given that dumpbin is not
available everywhere except
>> >> >>>>>> > Windows?
>> >> >>>>>> >   // Yeah, I should have looked
at the DwarfDebug LIT tests
>> >> >>>>>> > and
>> >> >>>>>> >   // written some; but the
prototype development went faster
>> >> >>>>>> >   // than I expected...
>> >> >>>>>>
>> >> >>>>>> I found the MCAsmStreamer being used
by llc which gives a decent
>> >> >>>>>> text
>> >> >>>>>> format.
>> >> >>>>>> I wrote a simple x86+x86_64 .ll test
and FileCheck expectations
>> >> >>>>>> for
>> >> >>>>>> the llc asm output.
>> >> >>>>>> Is this the right approach to write
tests?
>> >> >>>>>> If so, I'll convert my remaining
C program test cases into such
>> >> >>>>>> an
>> >> >>>>>> .ll+llc tests.
>> >> >>>>>>
>> >> >>>>>> > Can you suggest ways to split
this patch so it's easier
>> >> >>>>>> > to review part-by-part before
this hits trunk?
>> >> >>>>>>
>> >> >>>>>> Attached is an updated patch with a
new test and a few minor
>> >> >>>>>> things
>> >> >>>>>> improved.
>> >> >>>>>> I also removed the "TODO: test
on X64" as I did try it on x64
>> >> >>>>>> and
>> >> >>>>>> no
>> >> >>>>>> changes were required.
>> >> >>>>>>
>> >> >>>>>> Looking forward to your feedback!
>> >> >>>>>>
>> >> >>>>>> > Thanks!
>> >> >>>>>> > --
>> >> >>>>>> > Timur Iskhodzhanov,
>> >> >>>>>> > Google
>> >> >>>>>>
>> >> >>>>>>
_______________________________________________
>> >> >>>>>> LLVM Developers mailing list
>> >> >>>>>> LLVMdev at cs.uiuc.edu        
http://llvm.cs.uiuc.edu
>> >> >>>>>>
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>> João Matos
>> >
>> >
>
>