I'm trying to parse the DWARF debug info to determine the functions from a stack trace address. If it works for my C functions (compiled with gcc), it doesn't for my C++ functions (compiled with g++)
My C functions all have a in the .debug_info table a DW_AT_low_pc and a DW_AT_low_high attribute which tell me what memory range this function is, e.g.
<1><17433>: Abbrev Number: 33 (DW_TAG_subprogram)
<17434> DW_AT_external : 1
<17434> DW_AT_name : (indirect string, offset: 0x4704): TLSCursor_init
<17438> DW_AT_decl_file : 1
<17439> DW_AT_decl_line : 46
<1743a> DW_AT_linkage_name: (indirect string, offset: 0x4536): _Z14TLSCursor_initP9TLSCursorP13TCPConnection
<1743e> DW_AT_low_pc : 0x1178ce
<17442> DW_AT_high_pc : 0x1b
<17446> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<17448> DW_AT_GNU_all_call_sites: 1
<17448> DW_AT_sibling : <0x17469>`
Most of my C++ methods, however most do NOT have such attributes:
`<2><144de>: Abbrev Number: 7 (DW_TAG_subprogram)
<144df> DW_AT_external : 1
<144df> DW_AT_name : (indirect string, offset: 0x3505): ~TLSNumber
<144e3> DW_AT_decl_file : 3
<144e4> DW_AT_decl_line : 23
<144e5> DW_AT_linkage_name: (indirect string, offset: 0x3510): _ZN9TLSNumberD4Ev
<144e9> DW_AT_accessibility: 1 (public)
<144ea> DW_AT_declaration : 1
<144ea> DW_AT_object_pointer: <0x144f2>
<144ee> DW_AT_sibling : <0x144fd>
Is there any reason for this? How can I determine the address range of a function in that case?
DWARF method definitions can be split into an "abstract" and "concrete" parts. For example, it might be used when you have a function that is inlined in multiple locations. All of the pc-invariant information is stored in the abstract entry, while the concrete entries will have a pointer to the abstract entry and add the pc values for this specific instance of the method.
Look through your dwarf info for another DW_AT_abstract_origin which points back to this.
Also, there's a DW_AT_declaration tag on this subprogram die which tells you that this is a declaration (e.g. from a header file), not necessarily a definition. I may be wrong about this being an abstract/concrete pair, it could be that this information is duplicated in a declaration die later in the dwarf.
Related
I am new to the programming language Smalltalk and I can't seem to figure out how to call a method with arguments. I've been playing around with some code and created some methods, like for example (in GNU Smalltalk):
bin: n num: k [
| i |
i := 1.
1 to:k do:[:j|
i := i * 2.
].
^i
]
I would now like to call this function and actually get an answer, like for example: bin: 4 num: 2 (don't know how to do this). How can I do that? Is it even right to write 'bin: n num: k' when creating a method like I have done?
Thanks in advance!
First, you need a receiver object, on which you want to invoke that method. You did not indicate in which class you have created your method, so I will just assume that you called it MyClass.
| myObject |
myObject := MyClass new.
Then you can send that message to (invoke that method on) myObject like this:
myObject bin: 4 num: 2
So you just write the message send (which will invoke the method) after the receiver.
I read how to init embed type, and a related Q&A.
What my problem is when compile this code, I got :
[Error] unknown field 'feature.DefaultSshHelper' in struct literal of type dala02
type FDH feature.DefaultSshHelper
type dala02 struct {
Md5_v string
feature.DefaultSshHelper
//FDH
}
var x_01_h1_p = &dala02{
Md5_v: "",
feature.DefaultSshHelper: feature.DefaultSshHelper{
//FDH: FDH{
// blabla
},
}
// use it by a interface []feature.CmdFioHelper{x_00_h1_p}
At first time, I thought it was an Exported problem, so I added this line 'type FDH feature.DefaultSshHelper'. Now, we have this error :
[Error] cannot use x_01_h1_p (type *dala02) as type feature.CmdFioHelper in array or slice literal:
*dala02 does not implement feature.CmdFioHelper (missing Getnextchecker method)
But a pointer of feature.DefaultSshHelper does implement feature.CmdFioHelper ( a interface ). So pointer of dala02 should also implement that, right? (reference form effective go)
There's an important way in which embedding differs from subclassing. When we embed a type, the methods of that type become methods of the outer type, but when they are invoked the receiver of the method is the inner type, not the outer one.
Question is how to fix this compile error, which line is wrong? I'm not a expert for golang, thanks for your advice :). BTW I do find some workaround.
When you refer to embedded fields, you have to leave out the package name of the embedded type, as the unqualified type name acts as the field name.
Spec: Struct types:
A field declared with a type but no explicit field name is an anonymous field, also called an embedded field or an embedding of the type in the struct. An embedded type must be specified as a type name T or as a pointer to a non-interface type name *T, and T itself may not be a pointer type. The unqualified type name acts as the field name.
So simply write:
var x_01_h1_p = &dala02{
Md5_v: "",
DefaultSshHelper: feature.DefaultSshHelper{
// blabla
},
}
Your other attempt type FDH feature.DefaultSshHelper falls short as this type declaration creates a new type with zero methods: the type FDH does not "inherit" the methods of feature.DefaultSshHelper. And thus any type that embeds FDH will also lack methods of feature.DefaultSshHelper.
I filed the following bug on September 28th, 2009. Sadly, I still did not get any response and the final version of the specification still is incorrect. Is this really a bug? If not, why not? If yes, what should I do?
The section that contains the bug is 5.4.5 (Method overriding): http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.4.5 in combination with the description of the INVOKEVIRTUAL opcode: http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.invokevirtual
According to 5.4.5 m1 can override m2 even if m1 is private. This can happen if creating .class files manually or combining the .class from two compilations.
In my example I have classes A and B with B extends A. I compiled these classes so that A contains a public method named f and B contains a private method, also named f (by first declaring both methods public, compiling, copying A.class to a safe place, removing the declaration of f in A and changing to private in B, then compile B and using the saved version of A.class).
When now running this, my current Oracle JVM outputs A (meaning the method f in A is invoked). According to the specification, B should be the output (meaning the method f in B should be invoked).
EDIT: Actually, B.f should be resolved. Invocation may fail because of access right checks for the resolved method, if the caller is not B. However, I believe the method resolution part is wrong.
I think that the definition in 5.4.5 should check the access rights of m1, not only m2.
public class A {
public void f();
Code:
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String A
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
}
public class B extends A {
private void f();
Code:
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String B
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
}
Thanks,
Carsten
Your issue has been addressed, finally. The current version of the Java 8 JVM specification contains the required clarification:
5.4.5 Overriding
An instance method mC declared in class C overrides another instance method mA
declared in class A iff either mC is the same as mA, or all of the following are true:
C is a subclass of A.
mC has the same name and descriptor as mA.
mC is not marked ACC_PRIVATE.
One of the following is true:
mA is marked ACC_PUBLIC; or is marked ACC_PROTECTED; or is marked neither
ACC_PUBLIC nor ACC_PROTECTED nor ACC_PRIVATE and A belongs to the same
run-time package as C.
mC overrides a method m' (m' distinct from mC and mA) such that m' overrides mA.
There is another addition in §4.10.1.5 “Type Checking Abstract and Native Methods”:
private methods and static methods are orthogonal to dynamic method dispatch,
so they never override other methods (§5.4.5).
Less than five years for a fix, that’s fast compared to some other issues…
Here is what I want to achieve. I identified a class which I defined as a struct to store class data. One of the methods of the class uses class-field as if it's pointer to vtable.
int __thiscall SignOn(struc_4 *this)
{
v1 = this;
if ( !v1->vtable_40194AE0 )
return E_UNEXPECTED;
v1->field_3E8 = 0;
if ( !sub_686F7193(v1) )
return (*(*v1->vtable_40194AE0 + 12))(v1->vtable_40194AE0, 0, 0); // sub_40128EEE
}
As you can see it calls 3rd function from vtable. In run-time I identified that vtable_40194AE0 points to array in .data section which looks like this
off_40194AE0 dd offset InternalQueryInterface
dd offset AddRef
dd offset Release
dd offset sub_40128EEE ; 3
dd offset sub_40128F8C
dd offset sub_4012C2E2 ; 5
Is there a way to tell somehow IDA that vtable_40194AE0 always points to vtable at 0x40194AE0 so given call in the pseudo-code will look like
return vtable_40194AE0->sub_40128EEE(v1->vtable_40194AE0, 0, 0);
?
I tried to set vtable_40194AE0 of the structure to be "user-defined offset" but it doesn't help :(
Thanks a lot !
Of course, it's possible!
Open "Structures" window, find your class struct (struc_4 in your case) and open it (if it was collapsed). Select vtable field (it should be at first place), press Y and enter the type declaration as a pointer to vtable struct in opened window (vtable_40194AE0* in your case). That's it.
You can make a structure representing the vtable, declare C types of its fields with Y (to be typed function pointers) and make the offset in the call [ecx+12] an offset of that structure with T. This way, IDA will recognize the call's arguments.
In the structure representing the class, set the type of vtable field to be a pointer to the vtable structure, then if you're lucky, decompiler will put things together and put the vtable structure field name into the call instead of an offset.
To my knowledge, no. IDA structs are merely provided to make the process of visualizing disassembled data easier. The most you can do is comment the call site to identify the actual virtual function being called.
This is a question for the older programmers.
Years ago, I encountered a dialect of Pascal which allowed a variable number of arguments, through some kind of extension.
Does anyone know of a current dialect of Pascal which allows a variable number of arguments?
Given that Pascal is not as popular as it used to be, I wouldn't be surprised if the answer is no.
BTW, it is more correct, isn't it, to say variable number of arguments, rather than parameters ?
No. The answer is based on the Pascal dialects that I have used; others may be different.
The reason is that Pascal pushes arguments onto the stack frame in order, so all arguments are accessed via a fixed offset from the stack pointer. C, by comparison, pushes arguments in reverse order, so defined parameters are at fixed offset, and you can access "extra" arguments via pointer arithmetic. I'll try some ASCII art:
Pascal C
---------------------
| extra arg |
--------------------- ---------------------
| 1st param | | 3rd param |
--------------------- ---------------------
| 2nd param | | 2nd param |
--------------------- ---------------------
SP -> | 3rd param | | 1st param |
--------------------- ---------------------
As for parameter versus argument: as I learned it, the function (method) defines its parameters, the caller passes arguments. That definition came, I believe, from a Fortran manual, so that should give you an idea of how old I am :-)
You can use optional arguments with delphi to get the same effect:
procedure Proc(const A: Integer; const B: Integer = 15);
Proc(10); // B = 15
Proc(20,30);
Or overloaded methods:
procedure Proc(const A: Integer); overload;
procedure Proc(const A,B: Integer); overload;
Proc(10); // Variant 1
Proc(20,30); // Variant 2
Or you can use a variable array for parameters:
procedure Message(const AMessage: string; const AArgs: array of const);
Message('Hello %s', [Name]);
Message('%s %s', [Greeting, Name]);
GNU-Pascal (gcc based) afaik maps 1:1 to C support. using function something(arg:pchar;...) like syntax
Delphi/Free Pascal has "array of const" support, which is a typesafe version, and a varargs directive for the C interfacing (D6 or D7+)
You are probably thinking of a library that was available for Turbo Pascal where they had a hack like this. My syntax is a bit a rusty for objects and descending from it.
type
TValue = object;
TInteger = object(TValue)
Value : Integer;
end
TString = object(TValue)
Value : String;
end
TParam = record
Value : TValue;
Param : TParam;
end;
TValue = object;
{ Definition of Function }
function Test (Arg : TParam);
{ Usage }
var
I : TInteger;
S : TString;
Test (TParam (I, TParam (S, nil));
You could just chain as many arguments as you wanted. The last one had to be terminated with nil.
Yes!
Use the params keyword:
procedure write(params args: array of Object);
begin
{...}
end;