RE: Recent fix proposals
> I would suggest holding off submitting a PR for a bit longer pending
> some further investigations..
>
> My initial reaction was that I have a problem with machine specific
> fixes, and would prefer to see a portable fix. I have
> forwarded the issues
> to my engineers to look at, since similar code is used in several
> test suites we maintain.
>
> I then decided to look at this specific test code and see
> where the same
> strategy is used elsewhere. I found that its used in one of the UNIX
> certification test suites, and that all UNIX certified systems are
> executing this code without the cited problems, including
> several 64-bit
> implementations (inc LP64 systems).
>
> So initial thoughts at the moment are that I would
> not want to accept these changes as is. I'll get a response from
> my engineers later in the week. I'll also discuss it in a couple
> of other forums I maintain to see what folks come up with.
I don't mind a more portable fix, if there is one. I did not
attempt one, not having access to the details of any other
architectures that might have a similar quirk.
Please do consider that on machines where this test passes
and the (indirect) function descriptor scheme is used, the test
appears not to be testing quite what it expects: it tests that
a function can be executed through a copied function descriptor,
not a copied function, and thus may or may not actually be
properly exercising the test for executable and memory protection
attributes that is intended by these three tests.
Mats
--
To UNSUBSCRIBE, email to lsb-test-request@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
Reply to: