[LV] Status of the toolchain build scripts?

[Mikkel Lauritsen]

Jan-Benedict Glaw <jbglaw at lug-owl.de> wrote:

--- snip ---

>> > Hmm, I guess it's the -f{,no-}unit-at-a-time thingie; try to drop it
>> > from arch/vax/Makefile .
>>
>> Thanks - that made the compile continue, but unfortunately not for long;
>> the assembler pretty quickly bites the dust because glibc detects memory
>> corruption while compiling arch/vax/kernel/signal.c .
>
> This looks like being somewhat easy to debug. Was the compiler build
> with debugging support? In that case:
>
> $ make V=1
>
> -> Copy the gcc command and run it by hand, with `-v' added.
>
> GCC will then print out the actual cc1 call.
>
> gdb /path/to/cc1
>>run <command line arguments from above here>
>
> Once it bites into the dust, "bt" or "bt full", maybe we can see
> something.

Having done this, I now have a piece of GCC generated assembly code that
makes the assember go boom - or rather, causes glibc to emit a message
about having detected memory corruption.

The backtrace seems pretty innocuous; I'd be more than happy to provide it
(or the assembly code) to anybody who has deeper insight into the inner
workings of the assembler.

I have bisected the input file, and as long as there are no more than 1102
lines in it the assembler works fine. Increasing the number of lines causes
a segmentation fault, followed by the memory corruption if I increase the
size even further.

So - my initial conclusion is that the assembler has a memory management
problem, and I'm going to try to see if I can dig deeper into it.

Best regards and thanks
  Mikkel
_______________________________________________
Linux-Vax mailing list
Linux-Vax at pergamentum.com
http://www.pergamentum.com/mailman/listinfo/linux-vax