Trying to debug a testsuite failure

[Paul Koning]

In running the gcc testsuite on pdp11, I get some failures like this:

collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 1 exit status
compilation terminated.
compiler exited with status 1
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions

While those tests flags are not terribly useful on a small memory platform like pdp11, I wouldn't expect a failure like that. Some tests with those flags do pass.

The real issue is that collect2 is apparently failing for no visible reason and without any helpful explanation of what it's trying to do. Any hints on how I might debug this?

paul

[Richard Biener]

Post by Paul Koning
collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 1 exit status
compilation terminated.
compiler exited with status 1
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
While those tests flags are not terribly useful on a small memory platform like pdp11, I wouldn't expect a failure like that. Some tests with those flags do pass.
The real issue is that collect2 is apparently failing for no visible reason and without any helpful explanation of what it's trying to do. Any hints on how I might debug this?

Try with -Wl,-debug -Wl,-v but then it already tells you that nm
failed somehow. So possibly debug
that via strace -f?

Richard.

Post by Paul Koning
paul

[Paul Koning]

Post by Richard Biener

Post by Paul Koning
collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 1 exit status
compilation terminated.
compiler exited with status 1
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
While those tests flags are not terribly useful on a small memory platform like pdp11, I wouldn't expect a failure like that. Some tests with those flags do pass.
The real issue is that collect2 is apparently failing for no visible reason and without any helpful explanation of what it's trying to do. Any hints on how I might debug this?

Try with -Wl,-debug -Wl,-v but then it already tells you that nm
failed somehow. So possibly debug
that via strace -f?
Richard.

Found the problem. By default (without a suitable linker script) the linker does not report memory overflow. The failing cases are all programs too large to fit in the 16 bit address space of the target.

I changed the board file to specify a linker script with explicit memory bounds, and a torture options override that omits the -O3 variants. Now I get sane results.

Thanks,

paul

[Jeff Law]

Post by Paul Koning

Post by Richard Biener

Post by Paul Koning
collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 1 exit status
compilation terminated.
compiler exited with status 1
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
While those tests flags are not terribly useful on a small memory platform like pdp11, I wouldn't expect a failure like that. Some tests with those flags do pass.
The real issue is that collect2 is apparently failing for no visible reason and without any helpful explanation of what it's trying to do. Any hints on how I might debug this?

Try with -Wl,-debug -Wl,-v but then it already tells you that nm
failed somehow. So possibly debug
that via strace -f?
Richard.

Found the problem. By default (without a suitable linker script) the linker does not report memory overflow. The failing cases are all programs too large to fit in the 16 bit address space of the target.
I changed the board file to specify a linker script with explicit memory bounds, and a torture options override that omits the -O3 variants. Now I get sane results.

Yea. You also have to watch out for things which fit in the memory map
statically but where your stack/heap will collide at runtime. I saw
this all the time when I used to do embedded work on 16 bit targets.

jeff