Roger S
Posts: 3
Joined: Sun Jan 07, 2018 10:05 pm

Segmentation Faults

Tue Oct 02, 2018 7:53 pm

I am trying to port a version of Forth to a RPi 3 in assembler and I am being plagued by segmentation faults. Most of them I can find a cause and correct it but I am geting a number of elusive faults which I cannot resolve. I have a block of code which is working but ofter when I try to add code or date words the existing code creates segmentation faults at places which have worked well. Often the new code is in a different part of the program which has not even been run at the time of the fault.

The effect seems to be that adding code or data is moving parts of the program to far from each other and causing trouble although I can't see why this is not picked up by the linker.
I am using as to assemble and ld to link the program.

I know I have not given many details of the actual code as I don't expect anyone to struggle through several hundred lines of threaded code but if anyone has any thoughts on possible causes I would be very grateful.

Many thanks in advance,

Roger S

rzusman
Posts: 327
Joined: Fri Jan 01, 2016 10:27 pm

Re: Segmentation Faults

Wed Oct 03, 2018 3:47 am

This is what's know as a "Heisenbug."
They are mostly caused by writing past the end of an array, somewhere else in the program, or writing through an incorrect pointer (at least in C - I dunno about forth). Depending on where the array is (on the stack, for instance), writing past the end of it will not trigger an immediate segfault. Rather, it will write into some other variable and cause another function to segfault at a later time. These types of errors are very hard to track down. Good luck.

LdB
Posts: 868
Joined: Wed Dec 07, 2016 2:29 pm

Re: Segmentation Faults

Wed Oct 03, 2018 5:27 am

Some comments aside from agreeing with the above:

- The linker would error if it knew things were to far apart.

- You have blocks of code (functions etc you even describe that) the alignment of blocks of code should never be in question
- Use .balign 4 prologue above each block label
- The extension of that use an .ltorg epilogue for the assembler macros that us "=" sign to place literals aligned at end of code block

Code: Select all

.balign	4
function1:
     //..... function 1 assembler code
.balign 4
.ltorg

.balign	4
function2:
     //..... function 2 assembler code
.balign	4
.ltorg
That guarantees that any code block is aligned and the literals created from the assembler macro like ldr r0, =???? are aligned
Strictly the alignment before the ltorg shouldn't be needed unless you do weird things inside the code itself like insert constant data.

Usually we go beyond that each function block would be in it's own .text.sectionname so that it can be picked off by the garbage collector that if the code section is not used it is thrown out by the linker.

That the leaves only data and stack alignment to worry about.

It is the old case you can leave the prologues and epilogues out but then you live and die by the sword.

Roger S
Posts: 3
Joined: Sun Jan 07, 2018 10:05 pm

Re: Segmentation Faults

Fri Oct 05, 2018 4:18 pm

Thank you for your ideas on this.

Is there a difference between .ltorg and .pool? I tried .ltorg but could not see any difference between it and the .pool directive I am already using.

I reordered the code and eliminated some included files by bringing them into the main file. This made the faults go away! Unfortunately I now don't know if the .ltorg directive is having the desired effect.

Meanwhile I continue to work on the program, maybe I'll get it running before the troubles reappear.

Regards Roger

LdB
Posts: 868
Joined: Wed Dec 07, 2016 2:29 pm

Re: Segmentation Faults

Fri Oct 05, 2018 5:08 pm

From the ARM manuals
.pool
This is a synonym for .ltorg.
If you want a reference last entry
http://web.mit.edu/rhel-doc/3/rhel-as-e ... tives.html

So exactly the same thing which controls your literal pool placement, use either.
There are a few duplicates btw, .globl and .global etc.

As I said above not having the prologue is more likely the problem, the epilogue shouldn't matter except in some more creative coding but you know the saying it never hurts to be sure to be sure.

Return to “Bare metal, Assembly language”