The program available at this address: http://users.erols.com/whitaker/wordsall.zip compiles and executes correctly on native i686, but when cross-compiled for arm the resulting "words" executable prints out some introductory text and a prompt, but then segfaults as soon as any input is entered. The three helper programs "makedict", "makestem", and "makeinfl" execute and generate their output files correctly on arm, only the "words" program appears to be broken. It compiles with no warnings even with -pedantic and -Wall options, so if there are any errors in the code the compiler is not detecting them. I wouldn't expect bad Ada code to just segfault, anyway, because Ada has bounds checking and lacks pointers. I am trying to isolate the problem and produce a test case, but that is difficult because I don't know Ada very well. I'd be happy to provide any extra information that could be helpful.
I just cross-built ada-enabled gdb so hopefully I will be able to provide some more helpful information.
OK, gnat-gdb-5.3 is up and running on my zaurus, but it's still not much help because there's some problem with the debugging format (I compiled with the command "gnatmake -g words"): Die: DW_TAG_subrange_type (abbrev = 5, offset = 351607) has children: FALSE attributes: DW_AT_name (DW_FORM_string) string: "natural___XDLU_0__2147483647" DW_AT_lower_bound (DW_FORM_data1) constant: 0 DW_AT_upper_bound (DW_FORM_data4) constant: 2147483647 DW_AT_type (DW_FORM_ref4) constant: 121 Dwarf Error: Cannot find type of die. I'm experimenting with different debugging formats to see if I can get an actual backtrace or something.
I deleted all the binary files and recompiled with "gnatmake -gstabs words", but gdb still had dwarf errors. So either gdb isn't recognizing the correct debugging format or the gnat compiler is putting in broken debugging info. This happens both on native i686 and cross-compiling for arm. Of course I know next to nothing about stabs, dwarf, etc. so I could really use some help.
Tried it again and now I realize it doesn't always segfault on every input, in fact I noticed that if you type in, for example, "remotus" as the first word, it segfaults, but if you type in "in", "de", "quam", and "remotus" in order it parses and analyzes all of them perfectly without segfaulting. It seems pretty random which combinations of words make it work, but it definitely makes me think it's a problem with memory allocation or garbage collecting or something. Someone please help!
This report is really too general: could you please reduce the problem to a workable test case, with very precise intructions on how to reproduce the bug. Also, it's likely a code generation problem from what you are saying, rather than an Ada bug. Arno
No feedback in 3 months (T-4 days).