Re: port-hppa/56878 (hppa: kernel module lua fails to load)

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

The following reply was made to PR port-hppa/56878; it has been noted by GNATS.

From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
To: gnats-bugs%netbsd.org@localhost, Nick Hudson <nick.hudson%gmx.co.uk@localhost>
Cc: port-hppa-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: port-hppa/56878 (hppa: kernel module lua fails to load)
Date: Wed, 15 Jun 2022 17:48:36 -0400

 Nick Hudson <nick.hudson%gmx.co.uk@localhost> writes:
 >  On 15/06/2022 19:12, Tom Lane wrote:
 >>> ???  I am not sure how come the lua test is managing to pass with
 >>> your version,
  
 >  me either... I definitely tested it and saw it pass.
 
 Yeah, it passed for me too.  But on reflection maybe that's not so
 unexplainable: the test was failing before because a function-pointer
 comparison couldn't link.  The erroneous patch did fix that, but it
 would crash if that comparison was reached at runtime.  However,
 there's no reason to assume that this test case exercises the lua
 module very thoroughly, so it's easy to believe that the comparison
 isn't reached.
  
 >>> Poking about with gdb confirms that this crash is occuring at
 >>> a function pointer comparison.  (BTW, I wonder how that code
 >>> worked at all before this patch.)
  
 >  Probably some more rump symbol magic, i.e. it was getting the libgcc
 >  version until I added the libkern version. grrrrrr rump.
 
 Yeah.  In connection with PR 56788, I've been trying to trace down
 whether __libc_atomic_init gets called at all in the rump environment,
 and I'm just lost in a hall of mirrors :-(.  Probably somebody with
 more familiarity with librump needs to look at that one.
 
 			regards, tom lane