Using objdump utility, we are able to retrieved the relative address of a variable for example consider a simple C program:
Source-code:
#include<stdio.h>
void do_stuff(int my_arg){
int my_local=my_arg+2;
int i;
for(i=0;i<my_local;i++)
printf("i=%d\n",i);
}
int main(){
do_stuff(2);
return 0;
}
Compile with gcc :
$ gcc -g example.c -o example
Run objdump utility with dwarf flag for ELF information.
$objdump --dwarf=info example
Output:
Contents of the .debug_info section:
Compilation Unit # offset 0x0:
Length: 0xd3 (32-bit)
Version: 4
Abbrev Offset: 0x0
Pointer Size: 8
<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
<c> DW_AT_producer : (indirect string, offset: 0x0): GNU C 4.8.4 -mtune=generic -march=x86-64 -g -fstack-protector
<10> DW_AT_language : 1 (ANSI C)
<11> DW_AT_name : (indirect string, offset: 0xcd): sample1.c
<15> DW_AT_comp_dir : (indirect string, offset: 0x7e): /home/bernard/PhD/TEJAS/tejas_installation_kit/Tejas-Simulator/Tejas/benchmark
<19> DW_AT_low_pc : 0x40052d
<21> DW_AT_high_pc : 0x54
<29> DW_AT_stmt_list : 0x0
<1><2d>: Abbrev Number: 2 (DW_TAG_base_type)
<2e> DW_AT_byte_size : 8
<2f> DW_AT_encoding : 7 (unsigned)
<30> DW_AT_name : (indirect string, offset: 0x47): long unsigned int
<1><34>: Abbrev Number: 2 (DW_TAG_base_type)
<35> DW_AT_byte_size : 1
<36> DW_AT_encoding : 8 (unsigned char)
<37> DW_AT_name : (indirect string, offset: 0x62): unsigned char
<1><3b>: Abbrev Number: 2 (DW_TAG_base_type)
<3c> DW_AT_byte_size : 2
<3d> DW_AT_encoding : 7 (unsigned)
<3e> DW_AT_name : (indirect string, offset: 0xde): short unsigned int
<1><42>: Abbrev Number: 2 (DW_TAG_base_type)
<43> DW_AT_byte_size : 4
<44> DW_AT_encoding : 7 (unsigned)
<45> DW_AT_name : (indirect string, offset: 0x4c): unsigned int
<1><49>: Abbrev Number: 2 (DW_TAG_base_type)
<4a> DW_AT_byte_size : 1
<4b> DW_AT_encoding : 6 (signed char)
<4c> DW_AT_name : (indirect string, offset: 0x64): signed char
<1><50>: Abbrev Number: 2 (DW_TAG_base_type)
<51> DW_AT_byte_size : 2
<52> DW_AT_encoding : 5 (signed)
<53> DW_AT_name : (indirect string, offset: 0xf1): short int
<1><57>: Abbrev Number: 3 (DW_TAG_base_type)
<58> DW_AT_byte_size : 4
<59> DW_AT_encoding : 5 (signed)
<5a> DW_AT_name : int
<1><5e>: Abbrev Number: 2 (DW_TAG_base_type)
<5f> DW_AT_byte_size : 8
<60> DW_AT_encoding : 5 (signed)
<61> DW_AT_name : (indirect string, offset: 0x75): long int
<1><65>: Abbrev Number: 2 (DW_TAG_base_type)
<66> DW_AT_byte_size : 8
<67> DW_AT_encoding : 7 (unsigned)
<68> DW_AT_name : (indirect string, offset: 0xfb): sizetype
<1><6c>: Abbrev Number: 2 (DW_TAG_base_type)
<6d> DW_AT_byte_size : 1
<6e> DW_AT_encoding : 6 (signed char)
<6f> DW_AT_name : (indirect string, offset: 0x6b): char
<1><73>: Abbrev Number: 4 (DW_TAG_subprogram)
<74> DW_AT_external : 1
<74> DW_AT_name : (indirect string, offset: 0x59): do_stuff
<78> DW_AT_decl_file : 1
<79> DW_AT_decl_line : 2
<7a> DW_AT_prototyped : 1
<7a> DW_AT_low_pc : 0x40052d
<82> DW_AT_high_pc : 0x3f
<8a> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<8c> DW_AT_GNU_all_tail_call_sites: 1
<8c> DW_AT_sibling : <0xb9>
<2><90>: Abbrev Number: 5 (DW_TAG_formal_parameter)
<91> DW_AT_name : (indirect string, offset: 0xd7): my_arg
<95> DW_AT_decl_file : 1
<96> DW_AT_decl_line : 2
<97> DW_AT_type : <0x57>
<9b> DW_AT_location : 2 byte block: 91 5c (DW_OP_fbreg: -36)
<2><9e>: Abbrev Number: 6 (DW_TAG_variable)
<9f> DW_AT_name : (indirect string, offset: 0x3e): my_local
<a3> DW_AT_decl_file : 1
<a4> DW_AT_decl_line : 3
<a5> DW_AT_type : <0x57>
<a9> DW_AT_location : 2 byte block: 91 6c (DW_OP_fbreg: -20)
<2><ac>: Abbrev Number: 7 (DW_TAG_variable)
<ad> DW_AT_name : i
<af> DW_AT_decl_file : 1
<b0> DW_AT_decl_line : 4
<b1> DW_AT_type : <0x57>
<b5> DW_AT_location : 2 byte block: 91 68 (DW_OP_fbreg: -24)
<2><b8>: Abbrev Number: 0
<1><b9>: Abbrev Number: 8 (DW_TAG_subprogram)
<ba> DW_AT_external : 1
<ba> DW_AT_name : (indirect string, offset: 0x70): main
<be> DW_AT_decl_file : 1
<bf> DW_AT_decl_line : 9
<c0> DW_AT_type : <0x57>
<c4> DW_AT_low_pc : 0x40056c
<cc> DW_AT_high_pc : 0x15
<d4> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<d6> DW_AT_GNU_all_tail_call_sites: 1
<1><d6>: Abbrev Number: 0
I want to do as follows:-
I want to retrieved the address of a variable , say my_local. First I will look into DW_TAG_Variable, then DW_AT_name, DW_AT_location which was given by base register at function -20 from the top.
Question:
How to know the content of base register at run time.
Can we implement it using PinTool.
Question in broader sense:
I want variable my_local map to which address in memory given information from dwarf and Pintool.
Thanks in Advance.
You should be able to use Pin's SafeCopy function to access app memory and copy it into pintool memory.
But as noted in the comments, it's not always possible to know where variable values are stored reliably so keep this in mind.
Related
For example, I see the following output. I don't quite understand its complete meaning. But when I look at the figure, it is just black and white, without gray or other color.
$ file 0447.jpg
0447.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 1725x2751, components 1
The file size is 652708. To encode, 1725x2751 bits, the file size should be no more than 1725 * 2751/8 = 593184.4. But the file size is bigger than this.
So it seems that a pixel is not encoded as one bit. Is there a way to shrink the size of the file (without loss of info) so that one pixel is one bit (maybe using other formats)?
Don't use IM identify to find the actual bits-per pixel. Use EXIFTOOL.
Input JPG:
Exiftool shows BitsPerSample of 8
exiftool -s -ee -g1 -u -n -D cow.jpg
---- ExifTool ----
- ExifToolVersion : 12.44
---- System ----
- FileName : cow.jpg
- Directory : .
- FileSize : 16214
- FileModifyDate : 2022:10:14 11:31:44-07:00
- FileAccessDate : 2022:10:14 11:31:44-07:00
- FileInodeChangeDate : 2022:10:14 11:31:44-07:00
- FilePermissions : 100644
---- File ----
- FileType : JPEG
- FileTypeExtension : JPG
- MIMEType : image/jpeg
- ImageWidth : 300
- ImageHeight : 300
- EncodingProcess : 0
- BitsPerSample : 8 <-------
- ColorComponents : 1
---- JFIF ----
0 JFIFVersion : 1 1
2 ResolutionUnit : 2
3 XResolution : 28
5 YResolution : 28
---- Composite ----
- ImageSize : 300 300
- Megapixels : 0.09
Threshold to GIF:
convert cow.jpg -threshold 50% cow_bw1.gif
Exiftool shows BitsPerPixel = 1
exiftool -s -ee -g1 -u -n -D cow_bw1.gif
---- ExifTool ----
- ExifToolVersion : 12.44
---- System ----
- FileName : cow_bw1.gif
- Directory : .
- FileSize : 2698
- FileModifyDate : 2022:10:14 11:44:17-07:00
- FileAccessDate : 2022:10:14 11:44:19-07:00
- FileInodeChangeDate : 2022:10:14 11:44:17-07:00
- FilePermissions : 100644
---- File ----
- FileType : GIF
- FileTypeExtension : GIF
- MIMEType : image/gif
---- GIF ----
- GIFVersion : 89a
0 ImageWidth : 300
2 ImageHeight : 300
4.1 HasColorMap : 1
4.2 ColorResolutionDepth : 8
4.3 BitsPerPixel : 1 <-------
5 BackgroundColor : 1
---- Composite ----
- ImageSize : 300 300
- Megapixels : 0.09
Threshold to PNG:
convert cow.jpg -threshold 50% cow_bw1.png
Exiftool shows BitDepth of 1
exiftool -s -ee -g1 -u -n -D cow_bw1.png
---- ExifTool ----
- ExifToolVersion : 12.44
- Warning : [minor] Text/EXIF chunk(s) found after PNG IDAT (may be ignored by some readers)
---- System ----
- FileName : cow_bw1.png
- Directory : .
- FileSize : 2251
- FileModifyDate : 2022:10:14 11:49:20-07:00
- FileAccessDate : 2022:10:14 11:49:21-07:00
- FileInodeChangeDate : 2022:10:14 11:49:20-07:00
- FilePermissions : 100644
---- File ----
- FileType : PNG
- FileTypeExtension : PNG
- MIMEType : image/png
---- PNG ----
0 ImageWidth : 300
4 ImageHeight : 300
8 BitDepth : 1 <-------
9 ColorType : 0
10 Compression : 0
11 Filter : 0
12 Interlace : 0
- Gamma : 2.2
- BackgroundColor : 1
- ModifyDate : 2022:10:14 18:49:20
- Datecreate : 2022-10-14T18:31:44+00:00
- Datemodify : 2022-10-14T18:31:44+00:00
- Datetimestamp : 2022-10-14T18:49:19+00:00
---- PNG-pHYs ----
0 PixelsPerUnitX : 2800
4 PixelsPerUnitY : 2800
8 PixelUnits : 1
---- Composite ----
- ImageSize : 300 300
- Megapixels : 0.09
ADDITION
Here is how to make a 2-bit TIFF file.
convert lena.jpg -colorspace gray -depth 2 -type palette lena_d2.tif
exiftool -s -ee -g1 -u -n -D lena_d2.tif
---- ExifTool ----
- ExifToolVersion : 12.44
---- System ----
- FileName : lena_d2.tif
- Directory : .
- FileSize : 16642
- FileModifyDate : 2022:10:14 16:42:42-07:00
- FileAccessDate : 2022:10:14 16:42:43-07:00
- FileInodeChangeDate : 2022:10:14 16:42:42-07:00
- FilePermissions : 100644
---- File ----
- FileType : TIFF
- FileTypeExtension : TIF
- MIMEType : image/tiff
- ExifByteOrder : II
---- IFD0 ----
256 ImageWidth : 256
257 ImageHeight : 256
258 BitsPerSample : 2 <------
259 Compression : 1
262 PhotometricInterpretation : 3
266 FillOrder : 1
273 StripOffsets : 8
274 Orientation : 1
277 SamplesPerPixel : 1
278 RowsPerStrip : 256
279 StripByteCounts : 16384
282 XResolution : 72
283 YResolution : 72
284 PlanarConfiguration : 1
296 ResolutionUnit : 2
297 PageNumber : 0 1
320 ColorMap : (Binary data 24 bytes, use -b option to extract)
---- Composite ----
- ImageSize : 256 256
- Megapixels : 0.065536
I have a SureMark 4610 printer that I'm trying to connect to, but for some reason it hangs when I connect. I've installed the necessary drivers for the printer. What could be the problem?
I'm using Windows 10 if that is of any use to you all.
Here's the printer device info
DEVICE ID 04b3:4535 on Bus 000 Address 019 =================
bLength : 0x12 (18 bytes)
bDescriptorType : 0x1 Device
bcdUSB : 0x110 USB 1.1
bDeviceClass : 0x0 Specified at interface
bDeviceSubClass : 0x0
bDeviceProtocol : 0x0
bMaxPacketSize0 : 0x40 (64 bytes)
idVendor : 0x04b3
idProduct : 0x4535
bcdDevice : 0x216 Device 2.16
iManufacturer : 0x1 (c) Copyright IBM Corp. 2000
iProduct : 0x5 Printer Interface (Usage = 3500h, Usage Page = FF45h)
iSerialNumber : 0x3 060725163603C100193
bNumConfigurations : 0x1
CONFIGURATION 1: 0 mA ====================================
bLength : 0x9 (9 bytes)
bDescriptorType : 0x2 Configuration
wTotalLength : 0x22 (34 bytes)
bNumInterfaces : 0x1
bConfigurationValue : 0x1
iConfiguration : 0x0
bmAttributes : 0x40 Self Powered
bMaxPower : 0x0 (0 mA)
INTERFACE 1: Human Interface Device ====================
bLength : 0x9 (9 bytes)
bDescriptorType : 0x4 Interface
bInterfaceNumber : 0x1
bAlternateSetting : 0x0
bNumEndpoints : 0x1
bInterfaceClass : 0x3 Human Interface Device
bInterfaceSubClass : 0x0
bInterfaceProtocol : 0x0
iInterface : 0x5 Printer Interface (Usage = 3500h, Usage Page = FF45h)
ENDPOINT 0x82: Interrupt IN ==========================
bLength : 0x7 (7 bytes)
bDescriptorType : 0x5 Endpoint
bEndpointAddress : 0x82 IN
bmAttributes : 0x3 Interrupt
wMaxPacketSize : 0x10 (16 bytes)
bInterval : 0x4
Here is the simple code
from escpos import printer
p = printer.Usb(idVendor=0x04B3, idProduct=0x4535, timeout=10, in_ep=0x82)
print(p.idProduct)
I cannot get to the print because it just hangs indefinitely at line 2.
This question already has an answer here:
Timestamp function that has been working reliably just caused EXC_BAD_INSTRUCTION
(1 answer)
Closed 5 years ago.
My code, which use SimplePing:
func simplePing(_ pinger: SimplePing, didSendPacket packet: Data, sequenceNumber: UInt16) {
begin[String(sequenceNumber)] = Int(Date().timeIntervalSince1970 * 1000)//AppDelegate.swift:185
print("Send: \(Common.startCount)")
}
It works perfectly in my simulator and iPhone, but after made it available on AppStore, I received about 20 crash logs with some error like that:
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000000e7ffdefe
Triggered by Thread: 1
...
Thread 1 name:
Thread 1 Crashed:
0 ME 0x0011e5cc specialized AppDelegate.simplePing(SimplePing, didSendPacket : Data, sequenceNumber : UInt16) -> () + 652 (AppDelegate.swift:185)
1 ME 0x00116990 #objc AppDelegate.simplePing(SimplePing, didSendPacket : Data, sequenceNumber : UInt16) -> () + 68
2 ME 0x00116818 #objc AppDelegate.simplePing(SimplePing, didSendPacket : Data, sequenceNumber : UInt16) -> () + 40
3 ME 0x000f3348 -[SimplePing sendPingWithData:] + 640 (SimplePing.m:297)
...
I can't reproduce that crash, so I have to analysis that line of the code:
begin[String(sequenceNumber)]
begin initialized with begin = [String: Int](), so its type is [String : Int], and sequenceNumber's type is UInt16. So I think begin[String(sequenceNumber)] doesn't have any potential bug.
Int(Date().timeIntervalSince1970 * 1000)
And Int(Date().timeIntervalSince1970 * 1000) is just something like Int(aDouble * 1000), it seems correct in any situation.
So I get really confused with that crash log, could anyone please give me some hints?
From the docs for Int:
On 32-bit platforms, Int is the same size as Int32, and on 64-bit platforms, Int is the same size as Int64.
A signed 32-bit integer has a maximum value of 2,147,483,647.
At the moment, Int(Date().timeIntervalSince1970 * 1000) returns a value of 1,495,855,170,970.
That is significantly larger than what will fit in a 32-bit integer.
The crash is being caused by the overflow you are attempting when casting the Double to an Int when run on a 32-bit iOS device.
I would suggest an explicit use of Int64 instead of Int:
begin[String(sequenceNumber)] = Int64(Date().timeIntervalSince1970 * 1000)
is it possible via ctags to get the function end line number as well
"ctags -x --c-kinds=f filename.c"
Above command lists the function definition start line-numbers. Wanted a way to get the function end line numbers.
Other Approaches:
awk 'NR > first && /^}$/ { print NR; exit }' first=$FIRST_LINE filename.c
This needs the code to be properly formatted
Example:
filename.c
1 #include<stdio.h>
2 #include<stdlib.h>
3 int main()
4 {
5 const char *name;
6
7 int a=0
8 printf("name");
9 printf("sssss: %s",name);
10
11 return 0;
12 }
13
14 void code()
15 {
16 printf("Code \n");
17 }
18
19 int code2()
20 {
21 printf("code2 \n");
22 return 1
23 }
24
Input: filename and the function start line no.
Example:
Input: filename.c 3
Output: 12
Input : filename.c 19
Output : 23
Is there any better/simple way of doing this ?
C/C++ parser of Universal-ctags(https://ctags.io) has end: field.
jet#localhost tmp]$ cat -n foo.c
1 int
2 main( void )
3 {
4
5 }
6
7 int
8 bar (void)
9 {
10
11 }
12
13 struct x {
14 int y;
15 };
16
[jet#localhost tmp]$ ~/var/ctags/ctags --fields=+ne -o - --sort=no foo.c
main foo.c /^main( void )$/;" f line:2 typeref:typename:int end:5
bar foo.c /^bar (void)$/;" f line:8 typeref:typename:int end:11
x foo.c /^struct x {$/;" s line:13 file: end:15
y foo.c /^ int y;$/;" m line:14 struct:x typeref:typename:int file:
awk to the rescue!
doesn't handle curly braces within comments but should handle blocks within functions, please give it a try...
$ awk -v s=3 'NR>=s && /{/ {c++}
NR>=s && /}/ && c && !--c {print NR; exit}' file
finds the matching brace for the first one after the specified start line number s.
I'm working with the variant record below. The variable instance is Kro_Combi. SizeOf(Kro_Combi) reports 7812 bytes. SizeOf(Kro_Combi.data) reports 7810 bytes.
The sum of the SizeOf of all the other data structures composing the "non-directmode" case of the variant record also adds to 7810 bytes.
Why is there a two byte difference? I would like to have the two variant exactly overlay each other.
TKro_Combi = record
case directmode:boolean of
true : (
data : array[0..7809] of byte
);
false : (
Combi_Name : array[0..23] of char; //24
Gap1 : array[0..63] of byte; // 24-87 (64)
Ins_Effect_Group : array[1..12] of TIns_Effect_Params; //74 each, (Ins_Effect_Data=9 bytes) 74*12 = 888
Mast_Effect_Params : array[0..229] of byte; // 976-1205 : 230 bytes
Vect_Aud__Drum_Params : array[0..97] of byte; //1206-1303 : 98 bytes
Karma_Common : array[0..509] of byte; //1304-1813 : 510 bytes
Karma_Module : array[0..3] of TKarma_Module; //1814-2557 : 744 bytes each Total span 1814 - 4789 = 2976 bytes total
Common_Params : array[0..11] of byte; //4790-4801 = 12 bytes
Timbre_Group : array[1..16] of TTimbre_Params; ) // 4802 -4989 = 188 bytes each, 16 Timbres, 4802-7809 = 3008 bytes total for all
end;
First of all, there needs to be space for the directmode field. If you really want the record to have size 7810 bytes then you should remove that field. The other byte will be due to internal alignment and padding of the false part of the variant record. I can't yet quite work out where it comes from. No matter, you simply want to use a packed record to avoid any padding bytes.
TKro_Combi = packed record
case boolean of
true : (
data : array[0..7809] of byte
);
false : (
Combi_Name : array[0..23] of char; //24
Gap1 : array[0..63] of byte; // 24-87 (64)
Ins_Effect_Group : array[1..12] of TIns_Effect_Params; //74 each, (Ins_Effect_Data=9 bytes) 74*12 = 888
Mast_Effect_Params : array[0..229] of byte; // 976-1205 : 230 bytes
Vect_Aud__Drum_Params : array[0..97] of byte; //1206-1303 : 98 bytes
Karma_Common : array[0..509] of byte; //1304-1813 : 510 bytes
Karma_Module : array[0..3] of TKarma_Module; //1814-2557 : 744 bytes each Total span 1814 - 4789 = 2976 bytes total
Common_Params : array[0..11] of byte; //4790-4801 = 12 bytes
Timbre_Group : array[1..16] of TTimbre_Params; ) // 4802 -4989 = 188 bytes each, 16 Timbres, 4802-7809 = 3008 bytes total for all
end;