Hide Forgot
Description of problem: `disassemble /m <function>` seems to silently remove instructions. I understand that it might be a hard job due to optimizations, however, silently missing out on some instructions should probably be a avoided because it might be misleading. If this is a known weakness, then there should be at the very minimum a warning when the command has some chance of giving wrong results. Version-Release number of selected component (if applicable): I tried on the following versions with similar results : gdb-7.6.1-80.el7.x86_64 gdb-7.10.1-30.fc23.x86_64 How reproducible: 100% Steps to Reproduce: 1. debuginfo-install rpm 2. gdb /usr/bin/rpm 3. break main 4. run 5. disassemble /m headerVerifyInfo 6. disassemble headerVerifyInfo Actual results: The '/m' output is incorrect. In particular, the bswap instructions (corresponding to the ntohl() calls) instructions totally disappeared : 200 info->tag = ntohl(pe[i].tag); 0x00007ffff7b8024b <+91>: mov %r9d,(%rcx) 201 info->type = ntohl(pe[i].type); 0x00007ffff7b80255 <+101>: mov %r9d,0x4(%rcx) Expected results: Either of the following : 1- a complete output if possible The corresponding, but more correct version of above would probably be like : 200 info->tag = ntohl(pe[i].tag); 0x00007ffff7b80242 <+82>: mov (%rdx),%r9d 0x00007ffff7b80248 <+88>: bswap %r9d 0x00007ffff7b8024b <+91>: mov %r9d,(%rcx) 201 info->type = ntohl(pe[i].type); 0x00007ffff7b8024e <+94>: mov 0x4(%rdx),%r9d 0x00007ffff7b80252 <+98>: bswap %r9d 0x00007ffff7b80255 <+101>: mov %r9d,0x4(%rcx) Note: The instructions at +82, +88, +94 and +98 are shown nowhere in the /m output. 2- if gdb is unsure of the exactitude of the output, then a big warning should be printed, telling the user not to trust the data. Additional info: I ll attach the output of the disassembled function.
There is disas/s modifier now but not in RHEL, one can use DTS GDB for that. (In reply to Cedric Buissart from comment #0) > 2- if gdb is unsure of the exactitude of the output, then a big warning > should be printed, telling the user not to trust the data. GDB is perfectly sure with the output - it outputs the lines in source line first, instruction address second order. It is just not what the user expects. Keeping the Bug open as GDB could print some warning for /m but I am not sure, debugging -O2 -g code has many problems which is IMO a well known issue. (gdb) help disassemble Disassemble a specified section of memory. Default is the function surrounding the pc of the selected frame. With a /m modifier, source lines are included (if available). This view is "source centric": the output is in source line order, regardless of any optimization that is present. Only the main source file is displayed, not those of, e.g., any inlined functions. This modifier hasn't proved useful in practice and is deprecated in favor of /s. With a /s modifier, source lines are included (if available). This differs from /m in two important respects: - the output is still in pc address order, and - file names and contents for all relevant source files are displayed.
Thanks for the quick answer! Yah, a warning might be a good thing, or at the very least backporting the new /m help messages about lack of completeness.
Couldn't you use Developer Toolset GDB which already contains the /s option? Please reopen if you really ask for a RHEL backport. https://brewweb.engineering.redhat.com/brew/packageinfo?packageID=58668 -> http://download.eng.bos.redhat.com/brewroot/packages/devtoolset-6-gdb/7.12/29.el7/x86_64/devtoolset-6-gdb-7.12-29.el7.x86_64.rpm