I'm using the DIA SDK to get symbol information from .pdb files. For example, I want to use this to get a list of classes, functions, member variables, and so on from a project.
After some messing around I've been able to get this information, however I'm also getting a lot of extra stuff that isn't my own code but is added in after (by the standard library and such).
I've tried filtering this based on the source file of the given symbol, however get_sourceFileName() seems to be unreliable, usually not returning any value.
Any help would be appreciated, whether it's getting get_sourceFileName() to work properly or some other way of filtering out objects from code that isn't part of the project.
Note that I know there are alternatives to the DIA SDK that would make this easier, such as libclang, however those are not an option for this project for various reasons.
Related
A little configuration information to start:
Xcode 13
Qt 5.15.5
iOS 14.7.1 (18G82) (I'm running on a device, not a
simulator)
Host MacOS Big Sur 11.6
I'm debugging a large Qt app, all written in C++, except for the necessary few files to make it work in iOS (so it's really an Objective-C++ app with an enormous amount of native C++ linked to it, everything of Qt it needs). I have a break point within the LoadApplication method - Qt has been built from source for development (that is, in debug configuration with symbols). There are a number of native Qt QUrl objects whose values I'd like to inspect. I have successfully installed lldbbridge.py, but I think the problem may be unrelated to that, because I saw it when I was using other tricks to see the data without the bridge. There is a method called toString on the QUrl class that produces a text representation of the URL (and another called toDisplayString that may be more human readable). These methods produce (of course) QString objects. So here are the failure modes:
First the bridge should be helping me to inspect the QUrl and all I see are the raw object descriptions that hide all the private interfaces. It isn't.
before I installed the lldbbridge.py script, I was able to view some of these objects (local variables, but not parameters), using code like expr url.toString().toStdString().c_str(). It still might work on local variables, but I would really like to be able to inspect parameters as well.
the error feedback I get is
error: <lldb wrapper prefix>:21198:9: module 'std' not found
#import std;
~~~~~~~^~~
this is a pretty legit error, because I have scoured my system and the internet for evidence of this std.framework whose existence is implied, and cannot find it, though its name suggests that it would be an assist to Objective-C or Swift to deal with std::string and the like. Possibly it was a thing in Xcode 12 that has been dropped in Xcode 13, but if so, it has no footprint on the web that I can find. Still, presumably Qt 5.15.5's lldbbridge.py was compiled and run and against it at some point in the recent past.
this isn't the only trick that doesn't work when inspecting a QString, with or without the bridge. I also tried expr (const wchar_t*)url.toString().toUtf16() and expr (const char*)url.toString().toUtf8() and so forth. The same error feedback results, complaining about the mysterious "std" framework or module.
and don't get too hung up on QUrl objects, because I get the same result with other QStrings.
one more symptom: if I do an expr #import std; in the lldb command line, it appears to work. That is, it gives no error feedback and appears to complete. This just makes the world weirder, because if exists, it must be hiding somewhere inside Xcode's contents, but I've done file searches in there, and see no evidence of such a thing. And if it does exist, why is the lldb wrapper prefix giving me grief? Could the wrapper be underspecified in terms of framework search paths, but the lldb command line not?
So as if it's not too obvious, here are my questions (besides WTF???):
Am I the first to see this? I've seen some forum talk about string inspection no longer working for others in Xcode 13 lldb, but the specific failure mode is different. Anyone else see this?
Does anyone have any idea about this mysterious "std" framework or module? Could its functionality have been sucked up into some other module or framework for Xcode 13?
Any ideas about work-arounds that I haven't thought of? I'm not a complete lldb novice, but I'm not an expert either.
I'd like to turn up the log levels look at those for clues, but I've never used that feature before, and I don't really even know where to FIND the logs.
I notice that the feedback suggests that there are at least 21198 lines in this "wrapper" BEFORE we get to the failing import statement. Seems a little excessive to wrap a request to view the contents of a string. Perhaps the whole wrapper is corrupted in some way. Any thoughts on how to test that hypothesis? How about a way to inspect the contents of the wrapper prefix itself?
Could the #import std; be a red herring and just co-lateral damage in some other unrelated failure mode? It's tempting to imagine it's some kind of std library support thing, but I don't want to assume too much at this point.
one more things about "std", whatever it is - lldb is super dynamic. It's always compiling inline code on-the-fly to support its functionality. That's the whole llvm magic. Is it possible it exists only as some inline text within lldb's source? And again, if so, why is it only selectively available?
Well, that's my nightmare. Unless my setup is horribly corrupted in some way and it's my unique curse, I'm sure this problem will show up for others, so cogent answers will make you a hero. Any pointers are appreciated. Thanks.
I'm trying to write some complex Starlark rules that link and build multiple dynamic libraries on Linux using the (relatively) new cc_common APIs.
There seems to be 2 different ways you can create compile/link actions using this API:
Using the compile()/link() methods, which are relatively "high-level", and
Using the create_compile_variables()/create_link_variables() along with get_memory_inefficient_command_line() and then calling actions.run() directly with the generated command line.
In particualr, I'm trying to get #2 to work. My question is, how can I create the param_file to pass into create_link_variables? There doesn't seem to be any Starlark API for this.
https://docs.bazel.build/versions/1.1.0/skylark/lib/cc_common.html#create_link_variables
agoessling I have shared a couple of source files for you here
It should give you a pretty good idea of how this lower level cc_common API can be used end to end.
There are still known holes in this API, i.e. not everything possible with the built-in cc rules also possible through cc_common, but I would say 90% is available.
I am not associated with the Bazel team and the code is the result of my own digging and sniffing. No warranties, but it works for me. Let me know if you get stuck on something - I will try to help.
If you get an idea of how to do some of it better (prettier, more compatible with the built-in rules, more platform-independent, etc.) I am all ears. Good luck!
I want to be able to query what dependencies there are for C++ functions and variables in my source code. You could do that with Clang on the Linux side, but for Windows(.NET, etc) I can't seem to find a way to get access to the AST.
Background:
Say I fixed a part of my code. I'm trying to find a tool to easily identify all the areas in my source code affected by this fix. For example, if I changed Foo(), I'll check all areas that Foo() is used and all functions that Foo() calls, gather them, and print them out in a list. Preferably, it will also be able to gather multiple levels of dependencies. If it were to be represented visually, it'll look something like Sourcetrail. Unfortunately, I want to be able to do this programmatically instead of via a UI, so that link isn't what I'm looking for. I looked at DMS Search Engine but I can't seem to make its trial version to download. So I was wondering if I can just do it myself. But I can't seem to figure out how Sourcetrail, for example, was able to get the AST from a Visual Studio C++ project.
I want to programmatically download symbols from the micrsoft symbol server (http://msdl.microsoft.com/download/symbols).
E.g. given the name "ntdll.dll" I want to save the .pdb into any directory.
The APIs from dbghelp.dll seems to solve this. (http://msdn.microsoft.com/en-us/library/windows/desktop/ms679291%28v=vs.85%29.aspx)
But I don't know how to use them in a right way.
Does anyone did something like this before and can show me some example code?
thanks!
I never did something exactly like this, but I was intrigued enough to look. Your friends are the SymXxx functions, within dbghelp.dll.
Start with SymSetOptions followed by SymInitialize.
Then, the function that does the heavy lifting of the work is SymFindFileInPath. The second arguments (SearchPath) is a semicolon-separated search path, that may include SRV*.
The utility that does exactly what you want (pretty much, with nothing less and nothing more) is symchk.exe. Take a look at its imports table, notice it uses no more than 9 functions from dbghelp (and no 'networking' DLL such as winhttp or the like) - so that should give you a good clue how to proceed, and which methods you should use.
So there has been a lot of times where I needed to know what the enums returned by certain opengl operations are, to print them on the terminal to see what's going on.
It doesn't seem there's any kind of function available for stringifying the enums at the moment, so I'm thinking of going straight to gl.h (actually I'm gonna use libglew's header for now), grabbing the #defines and creating a huge switch table for convenience purposes.
Is there any better way, and how would you deal with having to port things to OpenGL ES?
gluErrorString is the function you're looking for in OpenGL, as GLU library is normally always available alongside with GL.
I don't have experience in OpenGL ES, but Google turned up GLUes that may help you.
OpenGL has some official .spec files that define the API, there is one enum.spec that lists all the enum names and their values. You just need to write a simple program to parse the file and produce a lookup mapping.
The file can be found at http://www.opengl.org/registry/ (specifically http://www.opengl.org/registry/api/enum.spec)
Manually processing gl.h would work but the spec files are updated for new versions and if you have a program to generate the code for you then you don't have to do anything to get the new enums in. Also gl.h file is implementation specific. So it might change between nVidia, ATI, and on different platforms.
The OpenGL Registry contains comprehensive information on the OpenGL API. Notably the gl.xml file in the XML API registry lists all enums, including their names and values. Creating a lookup table from that data should be simple enough.