| Summary: | Illegal instruction in "duma" when built with -O2 | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Aleksey <ioctl> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED MOVED | ||
| Severity: | normal | CC: | buildroot, yann.morin.1998 |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | Duma core dump test | ||
|
Description
Aleksey
2019-09-06 08:31:59 UTC
THanks for your bug report. However, the real question is why is duma failing in -O2 ? Rather than forcing -O0, it seems much more relevant to understand why it does not work when compiled in -O2. Could you get a core dump, and see on which instruction it crashes ? Which ARM processor are you using ? Its a specific debug tool, that works on low level, so, I think, author of the duma has a reason to use -O0 in original GNUmakefile. However, we can try to understand this reason. Unfortunately I was unable to get core dump in buildroot environment. How can I do it? As for the CPU, its a Marvell SOC. I have the following options in the configuration: BR2_ARCH="arm" BR2_ENDIAN="LITTLE" BR2_GCC_TARGET_ABI="aapcs-linux" BR2_GCC_TARGET_CPU="marvell-pj4" BR2_GCC_TARGET_FPU="vfpv3-d16" BR2_GCC_TARGET_FLOAT_ABI="softfp" BR2_GCC_TARGET_MODE="arm" Run "ulimit -c unlimited" before starting duma, and you will get a core dump. Which Marvell processor are you using ? Created attachment 8306 [details]
Duma core dump test
It's on the Marvell Poncat3 SOC CPU. Program text:
#include <stdio.h>
int main()
{
char *a;
a = malloc(1024);
a = realloc((void*)a, 2048);
free(a);
return 0;
}
Really weird... This is the disassembly around the faulting instruction: 0xb6e04694 <+672>: b 0xb6e046dc <__gettextparse+744> 0xb6e04698 <+676>: b 0xb6e046dc <__gettextparse+744> => 0xb6e0469c <+680>: b 0xb6e04ab8 <__gettextparse+1732> 0xb6e046a0 <+684>: b 0xb6e04a94 <__gettextparse+1696> 0xb6e046a4 <+688>: b 0xb6e049fc <__gettextparse+1544> 0xb6e046a8 <+692>: b 0xb6e049e4 <__gettextparse+1520> So it's in the middle of a switch table, simple relative branch instruction 0xea000105. The instructions that it jumps to all look pretty normal as well. However, duma does do weird things with the code. It is possible that the real fault is hidden by some exception handling within duma itself... gdb isn't able to print a proper backtrace, so that could be an indication... Thank you for your report.
The issue tracker for the Buildroot project has been moved to
the Gitlab.com issue tracker:
https://gitlab.com/buildroot.org/buildroot/-/issues
We are taking this opportunity to close old issues in this old
tracker. If you believe your issue is still relevant, please
open one in the new issue tracker.
Thank you!
|