On 10/23/18 11:05 AM, Paul Koning wrote: > > >> On Oct 23, 2018, at 6:08 AM, Richard Biener <richard.guent...@gmail.com> >> wrote: >> >> On Tue, Oct 23, 2018 at 2:39 AM Paul Koning <paulkon...@comcast.net> wrote: >>> >>> 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? >> >> 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
