Segfault in FallthroughFunctionPass #10
Labels
Comments
|
Does it also occur with the debug package?
…On Mar 2, 2018 13:05, "ethereal" ***@***.***> wrote:
libffi.so.6.gz
<https://github.com/columbia/egalito/files/1773679/libffi.so.6.gz>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQqjrpcTyxYa6X692fhaytdr7OoKv1iFks5taMUYgaJpZM4SZX3F>
.
|
|
I think it does, I'm on branch |
|
The direct cause for this is:
disassembly error? ffi_call_unix64 133 < 366
This function wasn't fully disassembled and so egalito thinks this is a
fall-through function. Then it searches for the following function, but it
cannot find one and dies.
I disassembled the library with objdump. The address 0x6071, which is 133
from the start of this function, is marked as (bad). I don't know X86_64
enough to tell why this address contains (bad). Does anybody have some
suggestions on how egalito should handle this?
Thanks!
…On Sat, Mar 3, 2018 at 7:54 AM, SleepyMug ***@***.***> wrote:
I think it does, I'm on branch merging
Welcome to the egalito shell version a5a63c8. Type "help" for usage.
egalito> parse2 /home/tenut/tmp/hey
creating ElfMap for file [/home/tenut/tmp/hey]
=== BUILDING ELF DATA STRUCTURES for [(executable)] ===
Number of version symbols: 12
Number of versions: 3
building relocation list
examining dependencies for ELF file
depends on shared library [libffi.so.6]
depends on shared library [libc.so.6]
library at [/usr/lib/x86_64-linux-gnu/libffi.so.6]
process [/usr/lib/x86_64-linux-gnu/libffi.so.6] a.k.a. libffi.so.6
added new library [libffi.so.6]
library at [/lib/x86_64-linux-gnu/libc.so.6]
process [/lib/x86_64-linux-gnu/libc.so.6] a.k.a. libc.so.6
added new library [libc.so.6]
--- RUNNING DEFAULT ELF PASSES for [(executable)] ---
Creating module from symbol info
WARNING: FallThrough: the last block was all NOPs
WARNING: FallThrough: the last block was all NOPs
WARNING: FallThrough: the last block was all NOPs
TIMING: 0.000057s for "FallThroughFunctionPass()"
Found data region at 0x0 size 0x97c
Found data region at 0x200df8 size 0x240
TIMING: 0.000009s for "HandleRelocsStrong(elf, relocList)"
TIMING: 0.000085s for "InternalCalls()"
TIMING: 0.000054s for "ExternalCalls(module->getPLTList())"
TIMING: 0.001051s for "SplitBasicBlock()"
TIMING: 0.000063s for "NonReturnFunction()"
TIMING: 0.000226s for "JumpTablePass()"
TIMING: 0.000008s for "JumpTableBounds()"
TIMING: 0.000005s for "JumpTableOverestimate()"
TIMING: 0.000115s for "SplitBasicBlock()"
TIMING: 0.000041s for "NonReturnFunction()"
TIMING: 0.000128s for "InferLinksPass(elf)"
found entry function [_start]
creating ElfMap for file [/usr/lib/x86_64-linux-gnu/libffi.so.6]
=== BUILDING ELF DATA STRUCTURES for [libffi.so.6] ===
creating ElfMap for file [/usr/lib/debug/.build-id/aa/1401f42d517693444b96c5774a62d4e8c84a35.debug]
Number of version symbols: 78
Number of versions: 6
building relocation list
examining dependencies for ELF file
depends on shared library [libc.so.6]
library at [/lib/x86_64-linux-gnu/libc.so.6]
--- RUNNING DEFAULT ELF PASSES for [libffi.so.6] ---
Creating module from symbol info
disassembly error? ffi_call_unix64 133 < 366
WARNING: FallThrough: the last block was all NOPs
WARNING: FallThrough: the last block was all NOPs
WARNING: FallThrough: the last block was all NOPs
etshell: pass/fallthrough.cpp:131: virtual void FallThroughFunctionPass::visit(Function*): Assertion `target' failed.
Aborted```
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AQqjriLi17qrOK7JUCWcj8K3PC_isQM8ks5tac26gaJpZM4SZX3F>
.
|
|
This is almost certainly an Intel/AMD-specific instruction which capstone
and objdump don't handle properly. I'll look into which instruction it is
and try to patch our capstone.
Meanwhile, if you are trying to disassemble libffi with symbols, maybe just
blacklist the symbols which don't disassemble correctly like this.
On Fri, Mar 2, 2018 at 8:08 PM, Hidenori Kobayashi <notifications@github.com
… wrote:
The direct cause for this is:
disassembly error? ffi_call_unix64 133 < 366
This function wasn't fully disassembled and so egalito thinks this is a
fall-through function. Then it searches for the following function, but it
cannot find one and dies.
I disassembled the library with objdump. The address 0x6071, which is 133
from the start of this function, is marked as (bad). I don't know X86_64
enough to tell why this address contains (bad). Does anybody have some
suggestions on how egalito should handle this?
Thanks!
On Sat, Mar 3, 2018 at 7:54 AM, SleepyMug ***@***.***>
wrote:
> I think it does, I'm on branch merging
>
> Welcome to the egalito shell version a5a63c8. Type "help" for usage.
> egalito> parse2 /home/tenut/tmp/hey
> creating ElfMap for file [/home/tenut/tmp/hey]
>
> === BUILDING ELF DATA STRUCTURES for [(executable)] ===
> Number of version symbols: 12
> Number of versions: 3
> building relocation list
> examining dependencies for ELF file
> depends on shared library [libffi.so.6]
> depends on shared library [libc.so.6]
> library at [/usr/lib/x86_64-linux-gnu/libffi.so.6]
> process [/usr/lib/x86_64-linux-gnu/libffi.so.6] a.k.a. libffi.so.6
> added new library [libffi.so.6]
> library at [/lib/x86_64-linux-gnu/libc.so.6]
> process [/lib/x86_64-linux-gnu/libc.so.6] a.k.a. libc.so.6
> added new library [libc.so.6]
> --- RUNNING DEFAULT ELF PASSES for [(executable)] ---
> Creating module from symbol info
> WARNING: FallThrough: the last block was all NOPs
> WARNING: FallThrough: the last block was all NOPs
> WARNING: FallThrough: the last block was all NOPs
> TIMING: 0.000057s for "FallThroughFunctionPass()"
> Found data region at 0x0 size 0x97c
> Found data region at 0x200df8 size 0x240
> TIMING: 0.000009s for "HandleRelocsStrong(elf, relocList)"
> TIMING: 0.000085s for "InternalCalls()"
> TIMING: 0.000054s for "ExternalCalls(module->getPLTList())"
> TIMING: 0.001051s for "SplitBasicBlock()"
> TIMING: 0.000063s for "NonReturnFunction()"
> TIMING: 0.000226s for "JumpTablePass()"
> TIMING: 0.000008s for "JumpTableBounds()"
> TIMING: 0.000005s for "JumpTableOverestimate()"
> TIMING: 0.000115s for "SplitBasicBlock()"
> TIMING: 0.000041s for "NonReturnFunction()"
> TIMING: 0.000128s for "InferLinksPass(elf)"
> found entry function [_start]
> creating ElfMap for file [/usr/lib/x86_64-linux-gnu/libffi.so.6]
>
> === BUILDING ELF DATA STRUCTURES for [libffi.so.6] ===
> creating ElfMap for file [/usr/lib/debug/.build-id/aa/
1401f42d517693444b96c5774a62d4e8c84a35.debug]
> Number of version symbols: 78
> Number of versions: 6
> building relocation list
> examining dependencies for ELF file
> depends on shared library [libc.so.6]
> library at [/lib/x86_64-linux-gnu/libc.so.6]
> --- RUNNING DEFAULT ELF PASSES for [libffi.so.6] ---
> Creating module from symbol info
> disassembly error? ffi_call_unix64 133 < 366
> WARNING: FallThrough: the last block was all NOPs
> WARNING: FallThrough: the last block was all NOPs
> WARNING: FallThrough: the last block was all NOPs
> etshell: pass/fallthrough.cpp:131: virtual void FallThroughFunctionPass::visit(Function*):
Assertion `target' failed.
> Aborted```
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#10 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/
AQqjriLi17qrOK7JUCWcj8K3PC_isQM8ks5tac26gaJpZM4SZX3F>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AArjF6WvJPNIebLnzcb6ouR7UyOUu8tZks5tae0ogaJpZM4SZX3F>
.
|
|
It is, quoting comments from vpk, another good reason to consider xed as x86_64 disassembler. (which disassemble |
|
I used xed, but it doesn't understand this either: There's a good reason for this, it's not actually valid instructions. From libffi source (unix64.S), we can see that this is in fact a manually specified inline jump table. I'll let Hidenori comment on how to handle this case. I guess the proper way would be to notice the lea of a suspiciously jump-table-like address, but that would mean going back and forth between disassembly, which we don't currently do. This is actually rather sloppy coding on the part of libffi, since this table could easily be embedded in the rodata section. Why do you need to handle libffi and is it OK to require symbols in this particular case? |
|
We aren't currently requiring to handle |
|
Debug symbols would be a little annoying to require, but certainly regular symbols (i.e. non-stripped binaries) would be fine. |
|
OK. Technically this function is hand-written assembly that violates Egalito's assumptions of reasonable compiler-generated code. So I would rather not add lots of hacks for it. If you are OK with including symbols, and it turns out you need libffi, we can put in a simple hack that skips the basic block at offset 71 during disassembly within the function named I think we should exit with a clear error message on x86_64 when disassembly fails. It should never really happen except for embedded data like this or unsupported instructions. I'll write a patch and consider this bug closed once that works. |
|
If we really need to handle this case, we can create
LinkedLiteralInstruction for the table entries at the disassembly stage and
make appropriate relative links afterward. Then, this will become somewhat
similar to AARCH64 case. Let me do some experiments if it becomes
necessary. I would expect it to take me for a couple of days.
Hidenori
On Mar 7, 2018 4:58 AM, "dwks" <notifications@github.com> wrote:
OK. Technically this function is hand-written assembly that violates
Egalito's assumptions of reasonable compiler-generated code. So I would
rather not add lots of hacks for it. If you are OK with including symbols,
and it turns out you need libffi, we can put in a simple hack that skips
the basic block at offset 71 during disassembly within the function named
ffi_call_unix64@@base <https://github.com/base>. Everything should then
work correctly.
I think we should exit with a clear error message on x86_64 when
disassembly fails. It should never really happen except for embedded data
like this or unsupported instructions. I'll write a patch and consider this
bug closed once that works.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#10 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AQqjrjzgjX9_njzf2440P9G6YC22LNr8ks5tbupJgaJpZM4SZX3F>
.
|
Merged
|
I think the manual specification of block boundaries that the parse override support enables is sufficient to call this dealt with. As @dwks mentioned it violates the assumption of compiler-generated code, so . . . |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Di (@SleepyMug) ran into a problem with parsing his
libffi.so.6(attached for reference), where it segfaults attempting to find function boundaries. The following lines from the debug output ofetobjdumpmay be relevant:The text was updated successfully, but these errors were encountered: