<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 12:25 PM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi David,<div><div class="h5"><br>
<br>
On 18/02/13 09:23, David Blaikie wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In the interests of centralizing the debug info metadata generation in one place<br>
(DIBuilder) the following patches (to DragonEgg, LLVM (to add a minor breaking<br>
API change), & Clang (to update for the breaking change) - any non-interesting<br>
API changes necessary have already been committed).<br>
<br>
I'll be the first to admit that this is a fairly mechanical transformation,<br>
simply replacing the raw metadata generation inside DragonEgg's DIFactory with a<br>
nested DIBuilder. With further consideration it would be quite easy to remove<br>
DIFactory entirely & use DIBuilder directly. This would most obviously tidy up<br>
the switches in DIFactory::CreateCompositeType and DIFactory::CreateDerivedType.<br>
<br>
Beyond that there's a couple of finer points:<br>
1) DIBuilder needed to be "finalized" - I chose to put that in DIFactory's dtor<br>
and add code to clean up the DIFactory at the appropriate point<br>
2) there's one case of raw MDNode creation for debug info metadata - see the<br>
comment in the DragonEgg patch starting "FIXME: Remove this conditional". If you<br>
remove it you can see the failure with a test case involving a<br>
pointer-to-member-variable typedef. (it seems the call to getOrCreateType at<br>
line 953 maybe needs to look through pointer-to-member-variable & create the<br>
type of the member being pointed to - that was a bit more involved that I was<br>
comfortable fixing, but fix welcome)<br>
<br>
[side note: currently DragonEgg seems to produce all record types as "struct"<br>
debug info, never using "class" debug info - I'm sure this would account for<br>
several failures in the GDB test suite & some minor usability confusion for users<br>
<br>
There is one test I'm still regressing (& a few that have improved with this<br>
patch) in the GDB 7.5 test suite: gdb.opt/inline-locals.exp, but I think that's<br>
just luck. It was mostly failing already, for slightly different reasons<br>
previously.]<br>
</blockquote>
<br></div></div>
thanks so much for doing this! The patch looks good, however it does cause some<br>
test suite failures:<br>
<br>
- dragonegg/test/validator/objc/<u></u>2010-02-23-DbgInheritance.m<br>
This objc test fails because it doesn't want DW_TAG_member, but gets it:<br>
<br>
!12 = metadata !{i32 786445, metadata !8, metadata !"", metadata !4, i32 8, i64 0, i64 8, i64 0, i32 0, metadata !11} ; [ DW_TAG_member ] [line 8, size 0, align 8, offset 0] [from P]<br>
<br>
Do you have any thoughts on this?<br></blockquote><div><br></div><div style>Hmm, I'll have to admit to having only run the GDB 7.5 test suite, not the DragonEgg tests.<br><br>Trying now, I get this error:<br><br><div>
aking DragonEgg 'test/dragonegg-lit.site.cfg' file...</div><div>sed: file lit.tmp line 3: unknown option to `s'</div><div>make: *** [test/dragonegg-lit.site.cfg] Error 1<br><br>do you have any idea about that?<br>
<br>(running "make check-validator" again produces a different error:<br><br><div>Running test suite 'validator'</div><div>Traceback (most recent call last):</div><div> File "/usr/local/google/home/blaikie/dev/llvm/src/utils/lit/lit.py", line 5, in <module></div>
<div> lit.main()</div><div> File "/usr/local/google/home/blaikie/dev/llvm/src/utils/lit/lit/main.py", line 280, in main</div><div> tests = lit.discovery.find_tests_for_inputs(litConfig, inputs)</div><div>
File "/usr/local/google/home/blaikie/dev/llvm/src/utils/lit/lit/discovery.py", line 201, in find_tests_for_inputs</div><div> test_suite_cache, local_config_cache)[1])</div><div> File "/usr/local/google/home/blaikie/dev/llvm/src/utils/lit/lit/discovery.py", line 101, in getTests</div>
<div> ts,path_in_suite = getTestSuite(path, litConfig, testSuiteCache)</div><div> File "/usr/local/google/home/blaikie/dev/llvm/src/utils/lit/lit/discovery.py", line 70, in getTestSuite</div><div> ts, relative = search(item)</div>
<div> File "/usr/local/google/home/blaikie/dev/llvm/src/utils/lit/lit/discovery.py", line 54, in search</div><div> cache[path] = res = search1(path)</div><div> File "/usr/local/google/home/blaikie/dev/llvm/src/utils/lit/lit/discovery.py", line 45, in search1</div>
<div> cfg = TestingConfig.frompath(cfgpath, None, litConfig, mustExist = True)</div><div> File "/usr/local/google/home/blaikie/dev/llvm/src/utils/lit/lit/TestingConfig.py", line 61, in frompath</div><div> exec f in cfg_globals</div>
<div> File "/usr/local/google/home/blaikie/dev/dragonegg/src/test/validator/validator-lit.cfg", line 26, in <module></div><div> path = os.path.pathsep.join((config.llvm_tools_dir, config.environment['PATH']))</div>
<div>AttributeError: TestingConfig instance has no attribute 'llvm_tools_dir'</div><div>make: *** [check-validator] Error 1</div></div><div style>)<br><br>For the record, I'm running this like:<br><br>GCC=$HOME/install/bin/gcc-4.7 CC=$HOME/dev/llvm/install/clang/debug/bin/clang CXX=$HOME/dev/llvm/install/clang/debug/bin/clang++ make check-validator<br>
</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- some Fortran testcases crash, but it's not your fault: it occurs with<br>
pointers to arrays, due to hitting this:<br>
<br>
if (isa<ARRAY_TYPE>(type) && TYPE_STRING_FLAG(type) &&<br>
isa<INTEGER_TYPE>(TREE_TYPE(<u></u>type))) {<br>
DEBUGASSERT(0 && "Don't support pascal strings");<br>
return DIType();<br>
}<br>
<br>
Then the empty DIType is used by the pointer code to try and form a<br>
derived type. I'm not sure why this (ancient) debug code thinks there<br>
is a problem with this kind of array, so I will try to fix it to handle<br>
them properly.</blockquote><div><br></div><div style>Thanks muchly,</div><div style><br></div><div style>- David </div></div></div></div>