AIRobot

AIRobot quick note


  • 首页

  • 关于

  • 标签

  • 分类

  • 归档

  • 搜索

gdb代码跳转调试

发表于 2020-10-10 更新于 2021-03-14
本文字数: 7.8k 阅读时长 ≈ 7 分钟

gdb代码跳转调试

不使用jump命令时怎么玩?

有时调试程序时,可能会出现因为某些错误f函数恒定为真/假,而又不想急于重新编译/搭建环境来解决这个问题。
这时,可以通过直接修改数据寄存器或者指令寄存器来达到目的(要清楚的知道f的影响范围,需要的寄存器)。

这里假设因为某些错误f恒为真,所以错误执行了f1分支,而实际上我们想执行的是f2.

示例代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <stdio.h>

int f()
{
return 1;
}

int f1()
{
printf("f1\n");
return 0;
}

int f2()
{
printf("f2\n");
return 0;
}

int main()
{
if (f())
f1();
else
f2();

return 0;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
(gdb) disassemble _start
Dump of assembler code for function _start:
0x0000000008001050 <+0>: xor %ebp,%ebp
0x0000000008001052 <+2>: mov %rdx,%r9
0x0000000008001055 <+5>: pop %rsi
0x0000000008001056 <+6>: mov %rsp,%rdx
0x0000000008001059 <+9>: and $0xfffffffffffffff0,%rsp
0x000000000800105d <+13>: push %rax
0x000000000800105e <+14>: push %rsp
0x000000000800105f <+15>: lea 0x19a(%rip),%r8 # 0x8001200 <__libc_csu_fini>
0x0000000008001066 <+22>: lea 0x133(%rip),%rcx # 0x80011a0 <__libc_csu_init>
0x000000000800106d <+29>: lea 0xfa(%rip),%rdi # 0x800116e <main>
0x0000000008001074 <+36>: callq *0x2f66(%rip) # 0x8003fe0
0x000000000800107a <+42>: hlt
End of assembler dump.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
(gdb) disassemble main
Dump of assembler code for function main:
0x000000000800116e <+0>: push %rbp
0x000000000800116f <+1>: mov %rsp,%rbp
0x0000000008001172 <+4>: mov $0x0,%eax
0x0000000008001177 <+9>: callq 0x8001135 <f>
0x000000000800117c <+14>: test %eax,%eax
0x000000000800117e <+16>: je 0x800118c <main+30>
0x0000000008001180 <+18>: mov $0x0,%eax
0x0000000008001185 <+23>: callq 0x8001140 <f1>
0x000000000800118a <+28>: jmp 0x8001196 <main+40>
0x000000000800118c <+30>: mov $0x0,%eax
0x0000000008001191 <+35>: callq 0x8001157 <f2>
0x0000000008001196 <+40>: mov $0x0,%eax
0x000000000800119b <+45>: pop %rbp
0x000000000800119c <+46>: retq
End of assembler dump.

f函数会将返回值放入rax寄存器,所以在f函数执行后,将rax寄存器修改为想要的值即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
(gdb) b f
Breakpoint 1 at 0x1139: file test.c, line 5.
(gdb) r
Starting program: /home/admin/a.out

Breakpoint 1, f () at test.c:5
5 return 1;
(gdb) i r
rax 0x0 0
rbx 0x0 0
rcx 0x7fffff79b718 140737479554840
rdx 0x7ffffffee708 140737488283400
rsi 0x7ffffffee6f8 140737488283384
rdi 0x1 1
rbp 0x7ffffffee600 0x7ffffffee600
rsp 0x7ffffffee600 0x7ffffffee600
r8 0x7fffff79cd80 140737479560576
r9 0x7fffff79cd80 140737479560576
r10 0xffffffff 4294967295
r11 0x0 0
r12 0x8001050 134221904
r13 0x7ffffffee6f0 140737488283376
r14 0x0 0
r15 0x0 0
rip 0x8001139 0x8001139 <f+4>
eflags 0x246 [ PF ZF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) until
6 }
(gdb) i r
rax 0x1 1
rbx 0x0 0
rcx 0x7fffff79b718 140737479554840
rdx 0x7ffffffee708 140737488283400
rsi 0x7ffffffee6f8 140737488283384
rdi 0x1 1
rbp 0x7ffffffee600 0x7ffffffee600
rsp 0x7ffffffee600 0x7ffffffee600
r8 0x7fffff79cd80 140737479560576
r9 0x7fffff79cd80 140737479560576
r10 0xffffffff 4294967295
r11 0x0 0
r12 0x8001050 134221904
r13 0x7ffffffee6f0 140737488283376
r14 0x0 0
r15 0x0 0
rip 0x800113e 0x800113e <f+9>
eflags 0x246 [ PF ZF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) set $rax=0
(gdb) c
Continuing.
f2
[Inferior 1 (process 34) exited normally]

因为这里f函数对其他范围无影响,可以不执行。CPU从何处执行指令是由CS、IP中的内容决定的,所以可以直接修改rip,直接执行f2.。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
(gdb) r
Starting program: /home/admin/a.out

Breakpoint 1, main () at test.c:22
22 if (f())
(gdb) disassemble
Dump of assembler code for function main:
0x000000000800116e <+0>: push %rbp
0x000000000800116f <+1>: mov %rsp,%rbp
=> 0x0000000008001172 <+4>: mov $0x0,%eax
0x0000000008001177 <+9>: callq 0x8001135 <f>
0x000000000800117c <+14>: test %eax,%eax
0x000000000800117e <+16>: je 0x800118c <main+30>
0x0000000008001180 <+18>: mov $0x0,%eax
0x0000000008001185 <+23>: callq 0x8001140 <f1>
0x000000000800118a <+28>: jmp 0x8001196 <main+40>
0x000000000800118c <+30>: mov $0x0,%eax
0x0000000008001191 <+35>: callq 0x8001157 <f2>
0x0000000008001196 <+40>: mov $0x0,%eax
0x000000000800119b <+45>: pop %rbp
0x000000000800119c <+46>: retq
End of assembler dump.
(gdb) i r
rax 0x800116e 134222190
rbx 0x0 0
rcx 0x7fffff79b718 140737479554840
rdx 0x7ffffffee708 140737488283400
rsi 0x7ffffffee6f8 140737488283384
rdi 0x1 1
rbp 0x7ffffffee610 0x7ffffffee610
rsp 0x7ffffffee610 0x7ffffffee610
r8 0x7fffff79cd80 140737479560576
r9 0x7fffff79cd80 140737479560576
r10 0xffffffff 4294967295
r11 0x0 0
r12 0x8001050 134221904
r13 0x7ffffffee6f0 140737488283376
r14 0x0 0
r15 0x0 0
rip 0x8001172 0x8001172 <main+4>
eflags 0x246 [ PF ZF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) set $rip=main+30
(gdb) i r
rax 0x800116e 134222190
rbx 0x0 0
rcx 0x7fffff79b718 140737479554840
rdx 0x7ffffffee708 140737488283400
rsi 0x7ffffffee6f8 140737488283384
rdi 0x1 1
rbp 0x7ffffffee610 0x7ffffffee610
rsp 0x7ffffffee610 0x7ffffffee610
r8 0x7fffff79cd80 140737479560576
r9 0x7fffff79cd80 140737479560576
r10 0xffffffff 4294967295
r11 0x0 0
r12 0x8001050 134221904
r13 0x7ffffffee6f0 140737488283376
r14 0x0 0
r15 0x0 0
rip 0x800118c 0x800118c <main+30>
eflags 0x246 [ PF ZF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) c
Continuing.
f2
[Inferior 1 (process 54) exited normally]

记一次linux大内存踩坑

发表于 2020-09-07
本文字数: 524 阅读时长 ≈ 1 分钟

内存变大后,索引表占了很大内存,tlb命中率也下降。

考虑从两点下手:

  1. 修改页框大小
  2. 使用大页内存

修改页框大小

kernel 2.6.30 menuconfig中没有页框大小配置项,这个版本还没有加入修改页框大小的功能。

找到page_types.h

1
#define PAGE_SHIFT    12

12就是4KB,打算修改成16即64KB。

修改后,编译失败。

大页内存

2.6.30支持大页内存,一般通过mount -t hugetlbfs和mmap来利用,但这导致需要修改不少程序代码。

还有一点就是程序使用的是否使用大量连续内存,否则会导致大量碎内存,使用内存池解决更好。

想不修改程序代码,考虑使用libhugetlbfs.so替换系统alloc。

这里又发现libhugetlbfs代码下的tests在2.6.30下编译不通过。原来是tests目录下一个文件打洞的标记此版本内核不支持(吐槽一下,官方doc写支持此版本,编译都不测一下吗)。反正是tests,冒险一下,先干掉。ok,编译通过。

又一坑。。。程序使用了tcmalloc,已经替换了一次malloc,所以这里还要在tcmalloc里写一个新的大页内存的malloc。

dpdk report bus error on arm64

发表于 2020-08-22
本文字数: 13k 阅读时长 ≈ 12 分钟

一开始以为是内存对齐导致的bus error。

最后发现是/var/run空间不足导致存不下大页信息。

参考链接
http://mails.dpdk.org/archives/users/2017-February/001590.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
Thank you Keith and Monroy, with your help I was able to track down the
problem, My var/run was too small to hold the hugepage information so when
I increased its size, it worked. Thank you so much.

On Thu, Feb 23, 2017 at 10:35 AM, Sergio Gonzalez Monroy <
sergio.gonzalez.monroy at intel.com> wrote:

> As Keith suggested, gdb is probably your best bet now.
> You could also do 'strace' to see if something shows up there.
>
> If you are running as root, the application is opening a file in /var/run
> to store some hugepage information, then it memsets to 0.
>
> What distro and kernel are you running on?
>
>
>
> On 23/02/2017 16:19, Sushil Adhikari wrote:
>
>> I didn't understand what you mean by hugepage value, if you mean number of
>> hugepages here's what it looks like
>> [~]$ grep -ri hugepages /proc/meminfo
>> AnonHugePages: 0 kB
>> HugePages_Total: 512
>> HugePages_Free: 512
>> HugePages_Rsvd: 0
>> HugePages_Surp: 0
>> Hugepagesize: 2048 kB
>>
>> And the linux version is 4.4.20.
>>
>> On Thu, Feb 23, 2017 at 9:17 AM, Wiles, Keith <keith.wiles at intel.com>
>> wrote:
>>
>> On Feb 22, 2017, at 7:18 PM, Sushil Adhikari <sushil446 at gmail.com>
>>>>
>>> wrote:
>>>
>>>> Thank you Keith for the response,
>>>>
>>>> Yes it should be line 1142 not 1405, I was using 16.11 and now I'm using
>>>>
>>> 17.02 and still getting the same error.
>>>
>>> Not sure what to say here, it looks like some type of system
>>> configuration
>>> issue as I do not see it on my machine.
>>>
>>> Can you tell if the hugepage has a value and is it sane? The next thing
>>> is
>>> to see where in that memory is it failing start, end or middle someplace.
>>> Use GDB and compile the code with ‘make install
>>> T=x86_64-native-lunixapp-gcc EXTRA_CFLAGS=“-g -O0”' then set a break
>>> point
>>> on ‘b eal_memory.c:1142’ and inspect the memory pointer hugepage. I do
>>> not
>>> think it is overrun error meaning the size for memset is different then
>>> what was allocated and just stepping off the end.
>>>
>>> Also you did not tell me the linux version you are using?
>>>
>>> On Wed, Feb 22, 2017 at 8:46 PM, Wiles, Keith <keith.wiles at intel.com>
>>>>
>>> wrote:
>>>
>>>> On Feb 22, 2017, at 6:43 PM, Wiles, Keith <keith.wiles at intel.com>
>>>>>
>>>> wrote:
>>>
>>>> On Feb 22, 2017, at 6:30 PM, Sushil Adhikari <sushil446 at gmail.com>
>>>>>>
>>>>> wrote:
>>>
>>>> I used the basic command line option "dpdkTimer -c 0xf -n 4"
>>>>>> And to update on my findings so far I have narrowed down to this
>>>>>>
>>>>> line(1405)
>>>
>>>> memset(hugepage, 0, nr_hugefiles * sizeof(struct hugepage_file));
>>>>>> of function rte_eal_hugepage_init() in file
>>>>>>
>>>>> dpdk\lib\librte_eal\linuxapp\eal\eal_memory.c
>>>
>>>> What version of DPDK are you using? I was looking at the file at 1405
>>>>>
>>>> and I do not see a memset() call.
>>>
>>>> I found the memset call at 1142 in my 17.05-rc0 code. Please try the
>>>>
>>> latest version and see if you get the same problem.
>>>
>>>> Yes I have the hugepages of size 2MB(2048) and when I calculate the
>>>>>>
>>>>> memory this memset function is trying to set, it comes out to
>>> 512(nr_hugefiles) * 4144 ( sizeof(struct hugepage_file) ) = 2121728 which
>>> larger than 2MB, so my doubt is that the hugepages I have
>>> allocated(512*2MB) is not contiguous 1GB memory its trying to access
>>> memory
>>> thats not part of hugepage, is that a possibility, even though I am
>>> setting
>>> up hugepages during boot time by providing it through kernel option.
>>>
>>>>
>>>>>> On Wed, Feb 22, 2017 at 8:05 PM, Wiles, Keith <keith.wiles at intel.com>
>>>>>>
>>>>> wrote:
>>>
>>>> On Feb 22, 2017, at 3:05 PM, Sushil Adhikari <sushil446 at gmail.com>
>>>>>>>
>>>>>> wrote:
>>>
>>>> Hi,
>>>>>>>
>>>>>>> I was trying to run dpdk timer app by setting 512 2MB hugepages but
>>>>>>>
>>>>>> the
>>>
>>>> application crashed with following error
>>>>>>> EAL: Detected 4 lcore(s)
>>>>>>> EAL: Probing VFIO support...
>>>>>>> Bus error (core dumped)
>>>>>>>
>>>>>>> If I reduce the number of hugepages to 256 it works fine. I
>>>>>>>
>>>>>> wondering what
>>>
>>>> could be the problem here. Here's my cpu info
>>>>>>>
>>>>>> I normally run with 2048 x 2 or 2048 per socket on my machine. What
>>>>>>
>>>>> is the command line you are using to start the application?
>>>
>>>> processor : 0
>>>>>>> vendor_id : GenuineIntel
>>>>>>> cpu family : 6
>>>>>>> model : 26
>>>>>>> model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
>>>>>>> stepping : 5
>>>>>>> microcode : 0x11
>>>>>>> cpu MHz : 2794.000
>>>>>>> cache size : 8192 KB
>>>>>>> physical id : 0
>>>>>>> siblings : 4
>>>>>>> core id : 0
>>>>>>> cpu cores : 4
>>>>>>> apicid : 0
>>>>>>> initial apicid : 0
>>>>>>> fpu : yes
>>>>>>> fpu_exception : yes
>>>>>>> cpuid level : 11
>>>>>>> wp : yes
>>>>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
>>>>>>>
>>>>>> pge mca
>>>
>>>> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>>>>>>>
>>>>>> syscall nx
>>>
>>>> rdtscp lm constant_tsc arch_
>>>>>>> perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni
>>>>>>>
>>>>>> dtes64
>>>
>>>> monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt
>>>>>>> lahf_lm ida dtherm tpr_shadow vnm
>>>>>>> i flexpriority ept vpid
>>>>>>> bugs :
>>>>>>> bogomips : 5600.00
>>>>>>> clflush size : 64
>>>>>>> cache_alignment : 64
>>>>>>> address sizes : 36 bits physical, 48 bits virtual
>>>>>>> power management:
>>>>>>>
>>>>>>> processor : 1
>>>>>>> vendor_id : GenuineIntel
>>>>>>> cpu family : 6
>>>>>>> model : 26
>>>>>>> model name : Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz
>>>>>>> stepping : 5
>>>>>>> microcode : 0x11
>>>>>>> cpu MHz : 2794.000
>>>>>>> cache size : 8192 KB
>>>>>>> physical id : 0
>>>>>>> siblings : 4
>>>>>>> core id : 1
>>>>>>> cpu cores : 4
>>>>>>> apicid : 2
>>>>>>> initial apicid : 2
>>>>>>> fpu : yes
>>>>>>> fpu_exception : yes
>>>>>>> cpuid level : 11
>>>>>>> wp : yes
>>>>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
>>>>>>>
>>>>>> pge mca
>>>
>>>> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>>>>>>>
>>>>>> syscall nx
>>>
>>>> rdtscp lm constant_tsc arch_
>>>>>>> perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni
>>>>>>>
>>>>>> dtes64
>>>
>>>> monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt
>>>>>>> lahf_lm ida dtherm tpr_shadow vnm
>>>>>>> i flexpriority ept vpid
>>>>>>> bugs :
>>>>>>> bogomips : 5600.00
>>>>>>> clflush size : 64
>>>>>>> cache_alignment : 64
>>>>>>> address sizes : 36 bits physical, 48 bits virtual
>>>>>>> power management:......
>>>>>>>
>>>>>>> And Here's my meminfo
>>>>>>>
>>>>>>> MemTotal: 24679608 kB
>>>>>>> MemFree: 24014156 kB
>>>>>>> MemAvailable: 23950600 kB
>>>>>>> Buffers: 3540 kB
>>>>>>> Cached: 31436 kB
>>>>>>> SwapCached: 0 kB
>>>>>>> Active: 21980 kB
>>>>>>> Inactive: 22256 kB
>>>>>>> Active(anon): 10760 kB
>>>>>>> Inactive(anon): 2940 kB
>>>>>>> Active(file): 11220 kB
>>>>>>> Inactive(file): 19316 kB
>>>>>>> Unevictable: 0 kB
>>>>>>> Mlocked: 0 kB
>>>>>>> SwapTotal: 0 kB
>>>>>>> SwapFree: 0 kB
>>>>>>> Dirty: 32 kB
>>>>>>> Writeback: 0 kB
>>>>>>> AnonPages: 9252 kB
>>>>>>> Mapped: 11912 kB
>>>>>>> Shmem: 4448 kB
>>>>>>> Slab: 27712 kB
>>>>>>> SReclaimable: 11276 kB
>>>>>>> SUnreclaim: 16436 kB
>>>>>>> KernelStack: 2672 kB
>>>>>>> PageTables: 1000 kB
>>>>>>> NFS_Unstable: 0 kB
>>>>>>> Bounce: 0 kB
>>>>>>> WritebackTmp: 0 kB
>>>>>>> CommitLimit: 12077660 kB
>>>>>>> Committed_AS: 137792 kB
>>>>>>> VmallocTotal: 34359738367 kB
>>>>>>> VmallocUsed: 0 kB
>>>>>>> VmallocChunk: 0 kB
>>>>>>> HardwareCorrupted: 0 kB
>>>>>>> AnonHugePages: 2048 kB
>>>>>>> CmaTotal: 0 kB
>>>>>>> CmaFree: 0 kB
>>>>>>> HugePages_Total: 256
>>>>>>> HugePages_Free: 0
>>>>>>> HugePages_Rsvd: 0
>>>>>>> HugePages_Surp: 0
>>>>>>> Hugepagesize: 2048 kB
>>>>>>> DirectMap4k: 22000 kB
>>>>>>> DirectMap2M: 25133056 kB
>>>>>>>
>>>>>> Regards,
>>>>>> Keith
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>> Keith
>>>>>
>>>> Regards,
>>>> Keith
>>>>
>>>>
>>>> Regards,
>>> Keith
>>>
>>>
>>>
>
`

checksum

发表于 2020-07-27 分类于 network
本文字数: 336 阅读时长 ≈ 1 分钟
1
2
3
4
5
/* Don't change this without changing skb_csum_unnecessary! */
#define CHECKSUM_NONE 0
#define CHECKSUM_UNNECESSARY 1 ///hardware verified the checksums
#define CHECKSUM_COMPLETE 2
#define CHECKSUM_PARTIAL 3 ///only compute IP header, not include data

CHECKSUM_COMPLETE
表明网卡已经计算了L4层报头和payload的校验和,并且skb->csum已经被赋值,此时L4层的接收者只需要加伪头并验证校验结果

asm

发表于 2020-06-23 更新于 2021-08-16
本文字数: 56 阅读时长 ≈ 1 分钟

https://www.ibm.com/developerworks/cn/linux/l-assembly/

1…567…26
AIRobot

AIRobot

AIRobot quick note
130 日志
15 分类
23 标签
GitHub E-Mail
Creative Commons
0%
© 2023 AIRobot | 716k | 10:51