Eric Christopher
2013-Dec-03 18:48 UTC
[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 > >
Timur Iskhodzhanov
2013-Dec-03 19:04 UTC
[LLVMdev] Adding line table debug information to LLVM on Windows
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>
Eric Christopher
2013-Dec-03 19:12 UTC
[LLVMdev] Adding line table debug information to LLVM on Windows
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 >> > >> > > >
Seemingly Similar Threads
- [LLVMdev] Adding line table debug information to LLVM on Windows
- [LLVMdev] Adding line table debug information to LLVM on Windows
- [LLVMdev] Adding line table debug information to LLVM on Windows
- [LLVMdev] Adding line table debug information to LLVM on Windows
- [LLVMdev] Adding line table debug information to LLVM on Windows