ESP8266 Community Forum

cal wrote:Should that probably be a break 1,x (coded) instead of break 0,x (planted) ?

Yeah, I think you're right. Pushed the update.
Thanks for checking!

jcmvbkbc wrote:

cal wrote:Should that probably be a break 1,x (coded) instead of break 0,x (planted) ?

Yeah, I think you're right. Pushed the update.
Thanks for checking!

Generates a



now after the code.

Can you explain to me the purpose of this?
Why would one execute a breakpoint AFTER the access?
Why does gcc believe to know that write and read access to address 0 should be treated as "kind of" fatal?
I say "kind of" because reading again about the ISA says "ignore if no debugger attached".
The gcc code generator treats is as fatal because any functions added after the access in my simple example above
are optimized away?

Confused,
Cal

cal wrote:Generates a

Code: Select allbreak 1,15

now after the code.

Can you explain to me the purpose of this?

Why would one execute a breakpoint AFTER the access?
Why does gcc believe to know that write and read access to address 0 should be treated as "kind of" fatal?

Because C (e.g. C99, 6.5.3.2:4) and C++ (e.g. C++98, 1.9:4) standards consider null-pointer dereference an undefined behaviour. The program that contains undefined behaviour is invalid, but GCC additionally tries to make sure that in case we reach that point we don't go any further. It's the "best effort" attempt, and in case there's a debugger connected, break 1, 15 fits perfectly. Without debugger it doesn't get any worse, since it's not guaranteed to work anyway.

jcmvbkbc wrote:

cal wrote:Generates a

Code: Select allbreak 1,15

now after the code.

Can you explain to me the purpose of this?

Why would one execute a breakpoint AFTER the access?
Why does gcc believe to know that write and read access to address 0 should be treated as "kind of" fatal?

Because C (e.g. C99, 6.5.3.2:4) and C++ (e.g. C++98, 1.9:4) standards consider null-pointer dereference an undefined behaviour. The program that contains undefined behaviour is invalid, but GCC additionally tries to make sure that in case we reach that point we don't go any further. It's the "best effort" attempt, and in case there's a debugger connected, break 1, 15 fits perfectly. Without debugger it doesn't get any worse, since it's not guaranteed to work anyway.

That makes sense to me.
Thanks for the explanation.

Cal