ESP8266 Community Forum

- Tue Jun 09, 2015 5:18 pm #19980

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!

- Wed Jun 10, 2015 3:00 am #20012

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

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?
I say "kind of" because reading again about

Code: Select allbreak 1,x

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

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG

- Wed Jun 10, 2015 5:32 am #20023

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.

- Wed Jun 10, 2015 7:09 am #20037

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

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG