8234905: [test] TestElfDirectRead fails on ARM32 due to missing call stack information

[christoph.goettschkes at microdoc.com]

Thanks for your input and for describing the process.

> Based on what I read in JDK-8234905, it seems like this bug isn't 
fixable
> in 32-bit ARM in thumb mode. Maybe I'm not reading it right...

Since the problem with this test is not the feature which is tested, but 
the method used to verify if everything works as expected, this bug could 
be fixed if a different verification mechanism would be used. Maybe the 
Whitebox?

But I guess re-writing the whole test because of one platform is not a 
good approach. I will suggest to disable the test (using an @requires tag) 
in a RFR. If required, one could write a new test for this feature which 
works on ARM32.

>    - if the problem is not fixable (e.g. the test scenario is not 
> supported by a given platform or configuration), then use @requires in 
> the test header, if possible
>       For example:  @requires !(vm.bits == "32" & os.arch == "arm")

>From my understanding, the os.arch property uses the system property 
os.arch [1]. This would mean that, arm actually means 32-bit arm, since 
for 64-bit arm, the system property os.arch is "aarch64". But I will test 
this and will propose the appropriate change in an RFR.

Thanks,
Christoph

[1] https://openjdk.java.net/jtreg/tag-spec.html

Mikhailo Seledtsov <mikhailo.seledtsov at oracle.com> wrote on 2019-12-04 
18:23:00:

> From: Mikhailo Seledtsov <mikhailo.seledtsov at oracle.com>
> To: daniel.daugherty at oracle.com
> Cc: christoph.goettschkes at microdoc.com, 
hotspot-runtime-dev at openjdk.java.net
> Date: 2019-12-04 18:22
> Subject: Re: 8234905: [test] TestElfDirectRead fails on ARM32 due to 
> missing call stack information
> 
> Hi Christoph,
> 
> General recommendation is as follows:
>    - if the error can be fixed, place the test on a problem list (follow 

> process described by Dan). Problem list supports exclusions per 
> platform, as well as general exclusions.
>    - if the problem is not fixable (e.g. the test scenario is not 
> supported by a given platform or configuration), then use @requires in 
> the test header, if possible
>       For example:  @requires !(vm.bits == "32" & os.arch == "arm")
> 
> Regards,
> Misha
> 
> On 12/4/19, 7:40 AM, Daniel D. Daugherty wrote:
> > Typically you create a subtask of the original bug with a synopsis 
> > like this:
> >
> >     ProblemList runtime/ElfDecoder/TestElfDirectRead.java
> >
> > and then use that bug to make the update to the ProblemList.txt file.
> >
> > However, I wonder if the right solution is some @requires directive
> > (but I don't know the right one).
> >
> > Based on what I read in JDK-8234905, it seems like this bug isn't 
fixable
> > in 32-bit ARM in thumb mode. Maybe I'm not reading it right...
> >
> > Dan
> >
> >
> > On 12/4/19 5:15 AM, christoph.goettschkes at microdoc.com wrote:
> >> Hi,
> >>
> >> I would like to add the test TestElfDirectRead to the ProblemsList 
(see
> >> [1]), because it is failing on 32-bit ARM. The bug report [2] 
describes
> >> why the test is failing and I currently don't see a trivial way to 
solve
> >> this issue. The issue is, that on ARM32 in thumb mode, HotSpot can 
not
> >> retrieve stack frames and hence, the reporting used in the test looks
> >> different from the reporting on other platforms.
> >>
> >> Do I need to create a new JBS issue for the change to the problems 
list,
> >> so the original bug stays open? Please advice.
> >>
> >> Thanks,
> >> Christoph
> >>
> >> [1]
> >> https://cr.openjdk.java.net/~cgo/8234905/webrev.00
> >> [2]
> >> https://bugs.openjdk.java.net/browse/JDK-8234905
> >>
> >
>