[LLVMdev] More DIFactory questions

[Renato Golin]

On 31 August 2010 17:03, Talin <viridia at gmail.com> wrote:
> 1) What types of DIScope are valid arguments for DebugLoc::get()? The method
> takes an MDNode* argument, so looking at the function signature is no help.
> For example, DIFile is a subtype of DIScope, however looking
> at DwarfDebug::recordSourceLine, I see that DIFile scopes are not valid for
> source lines.

Hi Talin,

I saw the same thing and I think it's an error in the code. There
shouldn't be any MDNode as arguments to DIFactory or DebugLoc or
anything related to creating debug information, otherwise, there is no
point in having those helpers. DIDescriptor has methods (isType,
isVariable, etc) to help, but MDNode doesn't (nor should).


> 2) What is the proper DIScope for executable code that is not part of a
> source-level function? For example, suppose I have code that is used to
> generate the initialization expression for a static variable. A similar
> example would be a default constructor, or any of the various implicit
> casting functions used when dealing with dynamic types. Now, although that
> code is in an LLVM function, that function was synthesized by the compiler
> and was never defined in any source file, so even if I were to create a
> DISubprogram scope for it, there's no valid source location information for
> it.
> If DIFile were allowed as a scope, then the issue would be straightforward,
> I would just declare the scope to be the source file.

I'm always passing DIDescriptor to DebugLoc::get(), which can be any
of DIFile, DISubprogram or DILexicalBlock...

Probably I'm bypassing the check, since the type now is DIDescriptor,
but I agree with you that DIFile should be accepted.

Another problem of not having real polymorphism... :/


> If my assumptions are correct, then, you can't have more than one
> DICompileUnit per module,

AFAIK, that is correct. Clang always set the "main_unit" to true.


> and the only way for code that was inlined from
> another module to indicate where it came from is to have a scope which is a
> DISubprogram, where that subprogram's DIFile is the file from where the code
> was defined. However, if the code didn't come from a function but was
> synthesized by the compiler, then I'm not sure how to generate a valid
> DISubprogram.

I don't understand why are you generating Dwarf symbols for compiler
generated code. If you can't represent that instruction in a source
line, why would you want to generate line information for it?

On "next", debuggers normally step to the next instruction with line
information that is not the same as the current, so there is no
problem in not issuing line info for compiler generated info. Also, on
"step", debuggers tend to stay in the same line until another
instruction with debug information is being processed, again,
unaffected by instructions without debug info.

The only thing I can think of doing with those is to print some
internal variables (VTT, TypeInfo, etc), and for that you can always
get the line info of the declaration (of the class, template, or
whatever).


-- 
cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm