8065585: Change ShouldNotReachHere() to never return

[David Holmes]

Hi Stefan,

trimming ...

On 16/04/2015 10:07 PM, Stefan Karlsson wrote:
> On 2015-04-16 04:23, David Holmes wrote:
>> Second, more important question: have you examined how this attribute
>> affects the ability to walk the stack? We have already seen issues on
>> some platforms where library functions, like abort(), have the
>> noreturn attribute and as a result the call is optimized in a way that
>> prevents the stack from being walked - see eg:
>>
>> https://git.matricom.net/Firmware/bionic/commit/5f32207a3db0bea3ca1c7f4b2b563c11b895f276
>>
>>
>> though this:
>>
>> https://www.raspberrypi.org/forums/viewtopic.php?t=60540&p=451729
>>
>> suggests that problem may have been addressed by the libc folk. But it
>> still raises the question as to how our own noreturn functions will be
>> handled and how they will affect stacktrace generation in hs_err logs
>> or via gdb.
>
> I added a call to fatal(...) in the GC code. I get correct stacktraces
> in gdb, but the stacktraces in the hs_err files are broken with
> fastdebug and product builds:

Which platforms?

> Stack: [0x00007f12518d2000,0x00007f12519d3000], sp=0x00007f12519d0eb0,
> free space=1019k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> V  [libjvm.so+0x11db44a]  VMError::report_and_die()+0x1ba
> V  [libjvm.so+0x7efb80]  report_vm_error(char const*, int, char const*,
> char const*)+0x90
> V  [libjvm.so+0x7efc49]  report_vm_error_noreturn(char const*, int, char
> const*, char const*)+0x9
> V  [libjvm.so+0x7efc63]
> V  [libjvm.so+0xfd7937]
> V  [libjvm.so+0xfeec51]
> ...

So what is the plan: try to get hs_err working again? Or file this under 
"well it seemed like a good idea"? ;-)

Cheers,
David

> Thanks,
> StefanK
>
>
>
>>
>> Thanks,
>> David
>>
>>>
>>> Thanks,
>>> StefanK
>>>
>