View mode: basic / threaded / horizontal-split · Log in · Help
April 29, 2007
suggestion: filenames output
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.
April 29, 2007
Re: suggestion: filenames output
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.
April 29, 2007
Re: suggestion: filenames output
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 ;).
April 29, 2007
Re: suggestion: filenames output
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 ;).
>
Top | Discussion index | About this forum | D home