Invalid test case on ARM
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linaro GCC |
Invalid
|
Medium
|
Unassigned | ||
libaio (Ubuntu) |
Confirmed
|
Medium
|
Unassigned |
Bug Description
Seen with libaio_
Starting cases/2.p
expect -14: io_setup(-1000, 0x10000) = -22 [Invalid argument] -- FAILED
expect -14: io_setup( 1000, 0x10000) = -22 [Invalid argument] -- FAILED
expect -14: io_setup( 0, 0x10000) = -22 [Invalid argument] -- FAILED
expect -22: io_setup(-1000, 0xbe8b0764) = -22 [Invalid argument]
expect -22: io_setup( -1, 0xbe8b0764) = -22 [Invalid argument]
expect -22: io_setup( 0, 0xbe8b0764) = -22 [Invalid argument]
expect 0: io_setup( 1, 0xbe8b0764) = 0 [Success]
expect -22: io_setup( 1, 0xbe8b0764) = -22 [Invalid argument]
test cases/2.t completed FAILED.
Completed cases/2.p with 1 -- FAILED.
May be armel or kernel specific.
Changed in gcc-linaro: | |
importance: | Undecided → Medium |
Changed in libaio (Ubuntu): | |
importance: | Undecided → Medium |
status: | New → Confirmed |
Changed in gcc-linaro: | |
status: | New → Invalid |
summary: |
- libaio fails during test with Linaro GCC + Invalid test case on ARM |
This clearly looks like a nonportable test case. It calls io_setup with an address of 0x10000 and expects to get EFAULT (-14), because the test assumes nothing will be mapped at 0x10000.
That assumption simply isn't true on arm, because the default linker script links applications to start at 0x8000.
This bug against Linaro GCC is invalid; I guess we could open a bug against libaio to fix the test case.