8065585: Change ShouldNotReachHere() to never return

[Stefan Karlsson]

On 2015-04-16 14:33, David Holmes wrote:
> 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?

On Linux x86 and x86_64.

>
>> 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"? ;-)

I'm leaning towards "seemed like a good idea", unless someone has an 
easy fix for these problems.

Thanks,
StefanK

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