librfxcodec icon indicating copy to clipboard operation
librfxcodec copied to clipboard

Q: How to test correctness of patches against asm files

Open mirabilos opened this issue 8 years ago • 11 comments

Hi,

I’ll need to patch the following files…

  • src/x86/rfxcodec_encode_dwt_shift_x86_sse2.asm
  • src/x86/rfxcodec_encode_dwt_shift_x86_sse41.asm

… in order to make them usable when compiled with PIC (shared library) or PIE (relocatable binary using PIC mechanism) without having a TEXTREL (which has bad security implications).

For this, I’ll require use of the ebx register (which stores the address of the GOT (global object table) with PIC code on i386), so I have to rewrite part of the code. How can I test correctness of my changes (in both (ELF) PIC and nōn-PIC modes) afterwards?

mirabilos avatar Jan 26 '17 17:01 mirabilos

There is an existing test (rfxcodectest.c) which should exercise those functions. You may want to add extra checks. It's very important to make sure that the test fails if the assembly code is incorrect. That way you know your code is executed.

To check PIC code, make sure the code you are testing is in a shared library. To check non-PIC more, use static linking. I suggest that you always write PIC code, it's easier to have one version.

proski avatar Jan 26 '17 19:01 proski

The test doesn’t help, as its scope seems to be a speed test, not a test for the correctness of the transformations.

No, we cannot always write PIC code, because the environment may be not a shared library or PIE binary (it can even be a nōn-ELF binary, although I only added ELF PIC for now).

I am fairly certain that the changed code will, at the very least, not crash; I just wonder about the correctness. (Especially as I discovered several pieces in the code that can be optimised further, but I stuck with mechanical transformations to enable ELF PIC for now.)

You can inspect my preliminary patches (uploaded to Debian “experimental” for actual user testing) here:

  • https://anonscm.debian.org/cgit/pkg-remote/xrdp.git/tree/debian/patches/i386-pic-asm-part1.diff?h=experimental
  • https://anonscm.debian.org/cgit/pkg-remote/xrdp.git/tree/debian/patches/i386-pic-asm-part2.diff?h=experimental

mirabilos avatar Jan 26 '17 19:01 mirabilos

There is no way to avoid having a test if correctness needs to be checked. Maybe @jsorg71 has some tests, he is the code author. If not, maybe there is a description of the functions somewhere?

proski avatar Jan 26 '17 20:01 proski

Can you provide some context what issue you are trying to fix? What OSes/distros/configurations are affected?

proski avatar Jan 26 '17 20:01 proski

I’m fixing that the assembly code cannot be used in PIC (such as libxorgxrdp.so) or PIE (executables) modules; this affects all ELF platforms where PIE is used for executables and/or librfxcodec is built as shared library and/or where X.org uses *.so format for modules instead of classic XFree86® *.a format.

mirabilos avatar Jan 26 '17 20:01 mirabilos

So, it should not affect the current xrdp builds, as they use the static library. Once the shared library is used, it would be a problem.

As for xorgxrdp, it would be affected now, as it's compiled to modules.

Is that how you see the issue?

But the way, there is non-assembly fallback for all functions. You can use it to understand the expected functionality.

proski avatar Jan 26 '17 21:01 proski

No, current xrdp builds are also affected since GCC now defaults to PIE.

I know about the non-assembly fallback (it’s used on all other architectures, like x32, anyway), but that doesn’t mean I understand that code.

mirabilos avatar Jan 26 '17 21:01 mirabilos

Should I add a sanity check encode of one tile for test?

jsorg71 avatar Feb 04 '17 08:02 jsorg71

Maybe a bitmap file could be added to the repository. Then rfxcodectest could be used to encode the bitmap. The checksum of the result could be compared to the expected checksum.

proski avatar Feb 04 '17 19:02 proski

I added rfxencode with #21 I can put test data on server1.xrdp.org that we can wget. Actually, I can put a huge test data set up there for extended testing.

jsorg71 avatar Feb 04 '17 20:02 jsorg71

I would rather have a small dataset that would cover most issues addressed in the code. We could use the same image converted to different color depths and different dimensions.

proski avatar Feb 04 '17 21:02 proski