tinygo

1837 Commits

99 Branches

41 Tags

26 MiB

Tree: 6ec868710b

Commit Graph

Author	SHA1	Message	Date
Ayke van Laethem	fcedf0beaa	stacksize: deal with DW_CFA_advance_loc1 In some cases this operation is emitted. It appears to be emitted when a switch is lowered to a jump table in the ARM backend.	4 years ago
Ayke van Laethem	50a677e9b7	arm: use CFI directives for stack usage Call Frame Information is stored in the .debug_frame section and is used by debuggers for unwinding. For assembly, this information is not known. Debuggers will normally use heuristics to figure out the parent function in the absence of call frame information. This usually works fine, but is not enough for determining stack sizes. Instead, I hardcoded the stack size information in stacksize/stacksize.go, which is somewhat fragile. This change uses CFI assembly directives to store this information instead of hardcoding it. This change also fixes the following error message that would appear in GDB: Backtrace stopped: previous frame identical to this frame (corrupt stack?) More information on CFI: * https://sourceware.org/binutils/docs/as/CFI-directives.html * https://www.imperialviolet.org/2017/01/18/cfi.html	4 years ago
Ayke van Laethem	d606315515	builder: try to determine stack size information at compile time For now, this is just an extra flag that can be used to print stack frame information, but this is intended to provide a way to determine stack sizes for goroutines at compile time in many cases. Stack sizes are often somewhere around 350 bytes so are in fact not all that big usually. Once this can be determined at compile time in many cases, it is possible to use this information when available and as a result increase the fallback stack size if the size cannot be determined at compile time. This should reduce stack overflows while at the same time reducing RAM consumption in many cases. Interesting output for testdata/channel.go: function stack usage (in bytes) Reset_Handler 332 .Lcommand-line-arguments.fastreceiver 220 .Lcommand-line-arguments.fastsender 192 .Lcommand-line-arguments.iterator 192 .Lcommand-line-arguments.main$1 184 .Lcommand-line-arguments.main$2 200 .Lcommand-line-arguments.main$3 200 .Lcommand-line-arguments.main$4 328 .Lcommand-line-arguments.receive 176 .Lcommand-line-arguments.selectDeadlock 72 .Lcommand-line-arguments.selectNoOp 72 .Lcommand-line-arguments.send 184 .Lcommand-line-arguments.sendComplex 192 .Lcommand-line-arguments.sender 192 .Lruntime.run$1 548 This shows that the stack size (if these numbers are correct) can in fact be determined automatically in many cases, especially for small goroutines. One of the great things about Go is lightweight goroutines, and reducing stack sizes is very important to make goroutines lightweight on microcontrollers.	4 years ago

Author

SHA1

Message

Date

Ayke van Laethem

fcedf0beaa

stacksize: deal with DW_CFA_advance_loc1

In some cases this operation is emitted. It appears to be emitted when a
switch is lowered to a jump table in the ARM backend.

4 years ago

Ayke van Laethem

50a677e9b7

arm: use CFI directives for stack usage

Call Frame Information is stored in the .debug_frame section and is used
by debuggers for unwinding. For assembly, this information is not known.
Debuggers will normally use heuristics to figure out the parent function
in the absence of call frame information.

This usually works fine, but is not enough for determining stack sizes.
Instead, I hardcoded the stack size information in
stacksize/stacksize.go, which is somewhat fragile. This change uses CFI
assembly directives to store this information instead of hardcoding it.

This change also fixes the following error message that would appear in
GDB:

    Backtrace stopped: previous frame identical to this frame (corrupt stack?)

More information on CFI:
  * https://sourceware.org/binutils/docs/as/CFI-directives.html
  * https://www.imperialviolet.org/2017/01/18/cfi.html

4 years ago

Ayke van Laethem

d606315515

builder: try to determine stack size information at compile time

For now, this is just an extra flag that can be used to print stack
frame information, but this is intended to provide a way to determine
stack sizes for goroutines at compile time in many cases.

Stack sizes are often somewhere around 350 bytes so are in fact not all
that big usually. Once this can be determined at compile time in many
cases, it is possible to use this information when available and as a
result increase the fallback stack size if the size cannot be determined
at compile time. This should reduce stack overflows while at the same
time reducing RAM consumption in many cases.

Interesting output for testdata/channel.go:

    function                                 stack usage (in bytes)
    Reset_Handler                            332
    .Lcommand-line-arguments.fastreceiver    220
    .Lcommand-line-arguments.fastsender      192
    .Lcommand-line-arguments.iterator        192
    .Lcommand-line-arguments.main$1          184
    .Lcommand-line-arguments.main$2          200
    .Lcommand-line-arguments.main$3          200
    .Lcommand-line-arguments.main$4          328
    .Lcommand-line-arguments.receive         176
    .Lcommand-line-arguments.selectDeadlock  72
    .Lcommand-line-arguments.selectNoOp      72
    .Lcommand-line-arguments.send            184
    .Lcommand-line-arguments.sendComplex     192
    .Lcommand-line-arguments.sender          192
    .Lruntime.run$1                          548

This shows that the stack size (if these numbers are correct) can in
fact be determined automatically in many cases, especially for small
goroutines. One of the great things about Go is lightweight goroutines,
and reducing stack sizes is very important to make goroutines
lightweight on microcontrollers.

4 years ago

3 Commits (6ec868710bc70ba1e40413f23df5bbc4f8cd889a)