digitalmars.D.debugger - suggestion: filenames output
- bobef (3/3) Apr 29 2007 In the following example there is no telling which is filename and which...
- Jascha Wetzel (3/8) Apr 29 2007 yeah, there is some bug with procedure demangling sitting around for a
- Frits van Bommel (45/54) Apr 29 2007 If you're using Phobos' std.demangle (are you even programming in D? I
- Jascha Wetzel (4/72) Apr 29 2007 ah, great, thanks!
In the following example there is no telling which is filename and which is something else, because there are spaces in what (I think) is supposed to be a function name: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at MFC3dwt7widgets5event5EventZv plugins.flowerui.FlowerUI.uilisten.handleEvent plugins\flowerui.d:42 (0x004341ab) So I think it will be a good idea to separate the filename with something that does not occur in both functions and filenames like asterix or something.
Apr 29 2007
yeah, there is some bug with procedure demangling sitting around for a while. i'll look into it. bobef wrote:In the following example there is no telling which is filename and which is something else, because there are spaces in what (I think) is supposed to be a function name: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at MFC3dwt7widgets5event5EventZv plugins.flowerui.FlowerUI.uilisten.handleEvent plugins\flowerui.d:42 (0x004341ab) So I think it will be a good idea to separate the filename with something that does not occur in both functions and filenames like asterix or something.
Apr 29 2007
Jascha Wetzel wrote:yeah, there is some bug with procedure demangling sitting around for a while. i'll look into it. bobef wrote:If you're using Phobos' std.demangle (are you even programming in D? I have no idea...) I already fixed this (and some other things) locally. Feel free to use it, or port the changes if you use a different programming language. (I've also submitted at least some of these improvements for it to bugzilla, but since they didn't seem to get merged in I'm not sure I've submitted *all* my local modifications) Attached is my modified version (as demangler.d). Modifications: * Formatting (mostly tabs -> spaces, I hate raw tabs :P). * Changed module name (since it's not the standard version) * Demangles member functions with "this" (style: "func_name(type1, type2, this)"). * Removed "bit", now correctly demangles 'b' as bool. * Demangles TypeInfo_[[mangled name]] to typeid(%s), where %s is the demangled postfix of the name (Exceptions are in place for names declared in object.d). * Support for nested identifiers (nested functions and static variables) * Demangles tuple types like this: "(X, Y, Z)". This is especially useful for their TypeInfo, which is demangled as "typeid((X, Y, Z))". (Note: TypeInfo of tuple types seems to be used to specify the TypeInfo[] passed to variadic functions such as writefln) * Removes superfluous 'Z' appended to __init, __ModuleInfo, etc. identifiers. * Added myself to the list of authors :). * Anything I missed when I just now looked at the sources in a diff viewer :). Also attached is a small application for use on the console. It based on the code in a comment in the original source (that demangles standard input to standard output), but adds a few features as well: * When called without command-line arguments, it behaves virtually the same (see next point for only difference). * Added "%s" before strings in writef, to avoid crashing on template names with '%' in string template parameters. * Files passed as arguments will be opened and read instead of standard input * Any arguments that aren't files will be demangled themselves. (The name (dfilt) was based on g++'s c++filt application) Note: IIRC templates with alias parameters don't get the alias parameters demangled. I'm not bothered enough by this to fix it; as a workaround, I just pipe the output through it once more... I will not claim my code is the best style, nor will I claim it has no bugs. All I will claim is that I've found this program extremely useful when examining objdump output piped through it ;).In the following example there is no telling which is filename and which is something else, because there are spaces in what (I think) is supposed to be a function name: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at MFC3dwt7widgets5event5EventZv plugins.flowerui.FlowerUI.uilisten.handleEvent plugins\flowerui.d:42 (0x004341ab) So I think it will be a good idea to separate the filename with something that does not occur in both functions and filenames like asterix or something.
Apr 29 2007
Jascha Wetzel <"[firstname]" mainia.de> ah, great, thanks! i suspected that there was something wrong with std.demangle, but i didn't look into it, yet. Frits van Bommel wrote:Jascha Wetzel wrote:yeah, there is some bug with procedure demangling sitting around for a while. i'll look into it. bobef wrote:If you're using Phobos' std.demangle (are you even programming in D? I have no idea...) I already fixed this (and some other things) locally. Feel free to use it, or port the changes if you use a different programming language. (I've also submitted at least some of these improvements for it to bugzilla, but since they didn't seem to get merged in I'm not sure I've submitted *all* my local modifications) Attached is my modified version (as demangler.d). Modifications: * Formatting (mostly tabs -> spaces, I hate raw tabs :P). * Changed module name (since it's not the standard version) * Demangles member functions with "this" (style: "func_name(type1, type2, this)"). * Removed "bit", now correctly demangles 'b' as bool. * Demangles TypeInfo_[[mangled name]] to typeid(%s), where %s is the demangled postfix of the name (Exceptions are in place for names declared in object.d). * Support for nested identifiers (nested functions and static variables) * Demangles tuple types like this: "(X, Y, Z)". This is especially useful for their TypeInfo, which is demangled as "typeid((X, Y, Z))". (Note: TypeInfo of tuple types seems to be used to specify the TypeInfo[] passed to variadic functions such as writefln) * Removes superfluous 'Z' appended to __init, __ModuleInfo, etc. identifiers. * Added myself to the list of authors :). * Anything I missed when I just now looked at the sources in a diff viewer :). Also attached is a small application for use on the console. It based on the code in a comment in the original source (that demangles standard input to standard output), but adds a few features as well: * When called without command-line arguments, it behaves virtually the same (see next point for only difference). * Added "%s" before strings in writef, to avoid crashing on template names with '%' in string template parameters. * Files passed as arguments will be opened and read instead of standard input * Any arguments that aren't files will be demangled themselves. (The name (dfilt) was based on g++'s c++filt application) Note: IIRC templates with alias parameters don't get the alias parameters demangled. I'm not bothered enough by this to fix it; as a workaround, I just pipe the output through it once more... I will not claim my code is the best style, nor will I claim it has no bugs. All I will claim is that I've found this program extremely useful when examining objdump output piped through it ;).In the following example there is no telling which is filename and which is something else, because there are spaces in what (I think) is supposed to be a function name: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at MFC3dwt7widgets5event5EventZv plugins.flowerui.FlowerUI.uilisten.handleEvent plugins\flowerui.d:42 (0x004341ab) So I think it will be a good idea to separate the filename with something that does not occur in both functions and filenames like asterix or something.
Apr 29 2007