Bug#892063: cpputest: FTBFS on hppa - __canonicalize_funcptr_for_compare (0xdeadbeef)

2018-03-10 Thread John David Anglin 

On 2018-03-10 3:39 AM, Raphael Hertzog wrote:

Given your work on the compiler, does it really make sense to try to fix
something in cpputest?

The only clean fix I can think of is to modify the tests to use a real
function pointer instead of 0xdeadbeef. I don't think that an architecture
specific work-around or fix is desirable here.
0xdeadbeef isn't a valid function pointer on hppa.  I would say using a 
real function pointer is correct:


Pointers to objects or functions of the same type (after pointer 
conversions) can be compared for equality.
Two pointers of the same type compare equal if and only if they are both 
null, both point to the same function,

or both represent the same address (3.9.2).

On systems that use function descriptors, it can be tricky to determine 
where a function pointer points due

to lazy binding, etc.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#892063: cpputest: FTBFS on hppa - __canonicalize_funcptr_for_compare (0xdeadbeef)

2018-03-10 Thread Raphael Hertzog 
Hi,

On Fri, 09 Mar 2018, John David Anglin wrote:
> Yes.  Function pointers on hppa differ from all other architectures. 
[...]
> I applied a patch to gcc-8 to fix the "0xdeadbeef" problem.  It adds a
> check to ensure that the pointer points to read accessible memory.  It
> also checks that the address in the descriptor is read accessible.  Will
> backport to 7 and 6 when I get a chance.

Given your work on the compiler, does it really make sense to try to fix
something in cpputest?

The only clean fix I can think of is to modify the tests to use a real
function pointer instead of 0xdeadbeef. I don't think that an architecture
specific work-around or fix is desirable here.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#892063: cpputest: FTBFS on hppa - __canonicalize_funcptr_for_compare (0xdeadbeef)

2018-03-09 Thread John David Anglin 

On 2018-03-09 7:59 PM, Raphael Hertzog wrote:

Thanks for the report, I forwarded it upstream but it seems strange that
hppa is the only architecture with such a problem. Is there something
special about this architecture that could explain this singularity?
Yes.  Function pointers on hppa differ from all other architectures.  
Firstly, there is a
bit in function pointers that determines whether or not the pointer 
points directly to
the function or a function descriptor.  The former mode is only used in 
a handful of
applications that don't link against shared libraries.  Secondly, the 
hppa runtime didn't
require that there be an official procedure descriptor for functions 
called indirectly.
As a result, there can be multiple function descriptors for any given 
function.  Thus,
one can't just compare function pointers directly.  One has to look into 
the function
descriptor and if necessary call into the dynamic linker to resolve the 
function's
address in the descriptor.  Once the descriptors are resolved, the 
pointers from the

descriptors can be compared.  The whole process is pretty horrible.

I applied a patch to gcc-8 to fix the "0xdeadbeef" problem.  It adds a 
check to ensure
that the pointer points to read accessible memory.  It also checks that 
the address in
the descriptor is read accessible.  Will backport to 7 and 6 when I get 
a chance.


Regards,
Dave Anglin

--
John David Anglin  dave.ang...@bell.net

Bug#892063: cpputest: FTBFS on hppa - __canonicalize_funcptr_for_compare (0xdeadbeef)

2018-03-09 Thread Raphael Hertzog 
Control: forwarded -1 https://github.com/cpputest/cpputest/issues/1145

Hi,

On Sun, 04 Mar 2018, John David Anglin wrote:
> It looks like __canonicalize_funcptr_for_compare needs to be improved to
> prevent access fault on garbage pointer, but maybe there's something that
> can be done in cpputest.

Thanks for the report, I forwarded it upstream but it seems strange that
hppa is the only architecture with such a problem. Is there something
special about this architecture that could explain this singularity?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#892063: cpputest: FTBFS on hppa - __canonicalize_funcptr_for_compare (0xdeadbeef)

2018-03-04 Thread John David Anglin 
Source: cpputest
Version: 3.8-7
Severity: normal

Dear Maintainer,

The build fails running CppUTestTests:
./CppUTestTests
!!..!..!..!..!
..!..!..!..!..!.!!.!..!...
..!..!..!make[2]: *** [Makefile:3402: tdd] Segmentation fault

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=cpputest=hppa=3.8-7=1520189685=0

Running under gdb:

Breakpoint 1, 0x000d7c24 in __canonicalize_funcptr_for_compare ()
(gdb) p/x $r26
$1 = 0xdeadbeef
(gdb) bt
#0  0x000d7c24 in __canonicalize_funcptr_for_compare ()
#1  0x000d637c in UtestShell::assertFunctionPointersEqual (
this=0x17b2fc 
,
 expected=,
actual=, text=0xee948 "Failed because it failed",
fileName=, lineNumber=, testTerminator=...)
at src/CppUTest/Utest.cpp:475
#2  0x00095f64 in 
TEST_UnitTestMacros_FUNCTIONPOINTERS_EQUAL_TEXTBehavesAsProperMacro_Test::testBody
 (this=) at tests/TestUTestMacro.cpp:734
#3  0x000d3ebc in helperDoTestBody (data=)
at src/CppUTest/Utest.cpp:92
#4  0x000d75b8 in PlatformSpecificSetJmpImplementation (
function=@0x16e6d2: 0xd3e98 , data=0x1891d0)
at src/Platforms/Gcc/UtestPlatform.cpp:144
#5  0x000d4474 in Utest::run (this=0xdeadbeef) at src/CppUTest/Utest.cpp:575

(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x000d7c50 in __canonicalize_funcptr_for_compare ()
(gdb) disass $pc-16,$pc+16
Dump of assembler code from 0xd7c40 to 0xd7c60:
   0x000d7c40 <__canonicalize_funcptr_for_compare+40>:  copy r26,r3
   0x000d7c44 <__canonicalize_funcptr_for_compare+44>:  addil L%9000,dp,r1
   0x000d7c48 <__canonicalize_funcptr_for_compare+48>:  ldw 488(r1),r21
   0x000d7c4c <__canonicalize_funcptr_for_compare+52>:  depwi 0,31,2,r3
=> 0x000d7c50 <__canonicalize_funcptr_for_compare+56>:  ldw 0(r3),ret0
   0x000d7c54 <__canonicalize_funcptr_for_compare+60>:  ldo 10(ret0),r20
   0x000d7c58 <__canonicalize_funcptr_for_compare+64>:  cmpb,= r21,r20,0xd7c70 
<__canonicalize_funcptr_for_compare+88>
   0x000d7c5c <__canonicalize_funcptr_for_compare+68>:  ldil L%-3ff2000,r31
End of assembler dump.

It looks like __canonicalize_funcptr_for_compare needs to be improved to
prevent access fault on garbage pointer, but maybe there's something that
can be done in cpputest.

Regards,
Dave Anglin

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.23+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)