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.

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.

Jascha Wetzel wrote:
> 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.

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 ;).

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:
>>> 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.
> 
> 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 ;).
>