dmik
commented
3 years ago Ok, I sorted it out. My dirty hack of EMXOMF was on the way see (https://github.com/bitwiseworks/libc/issues/82#issuecomment-638450071). Removing it solves the problem.
Closed dmik closed 3 years ago
dmik
commented
3 years ago Ok, I sorted it out. My dirty hack of EMXOMF was on the way see (https://github.com/bitwiseworks/libc/issues/82#issuecomment-638450071). Removing it solves the problem.
StevenLevine
commented
3 years ago As you determined, there is something unexpected about the object file format. We have seen something similar to this in the past, although the linker error differed.
FTR, the error triggered at:
obj2supp.c:256 case FIX_FRAME_SEG: if( !frame->u.sdata ) { LnkMsg( LOC+ERR+MSG_FIXUP_MISSING_THREAD, "dA", frame->type, tgt_addr ); // 2020-06-21 SHL break; }
which is handling relocation records. The error triggered because, u.sdata was never populated. As some point, we need to make emxomf a bit smarter about which debug data it strips.
dmik
commented
3 years ago @StevenLevine yeah thanks for the comment! And there is a chance we will have a NY set of RPMs then. I’m having various other problems though, totally unrelated (happened when cooking LIBC RPMs), but may be you have something to say about it as well:
StevenLevine
commented
3 years ago A bit more FTR. This error used to result in a trap. The message:
lnkerror.msg:345 // 2020-06-21 SHL pick( MSG_FIXUP_MISSING_THREAD, "Missing thread definition for type %d relocation for %A" , "Missing thread definition for type %d relocation for %A" )
was added at the same time the NULL pointer check was added to resolve #72.
StevenLevine
commented
3 years ago That's a nasty cascading exception IPE. The gory details are:
000FED9B: _trapQueryRegister+3A 000FED9B panic_FED9B: ; CODE XREF: _trapQueryRegist 000FED9B call __panicHIGH32 000FED9B ;──────────────────────────────────────────────────────────────────── 000FEDA0 dw 9084 000FEDA2 dw 60002 000FEDA2 _trapQueryRegister endp 000FEDA4
The IPE triggered because while processing an exception, a query client register request failed because the control information that provides access the the register was marked invalid. This typically indicates that kernel memory is corrupted, but it requires a system dump to say more.
Trying to make a New Year release of LIBC, I suddenly faced this build break at link stage:
This makes no sense to me. I've never seen this error in my entire practice. Last time I had a complete build of LIBC is for 0.1.5 RPM and it was on 22.06.2020. I have no idea what could change since then to make it break. On 23.06.2020 I released a new GCC 9.2.0 OS/2 beta 3 but there was just one change (https://github.com/bitwiseworks/gcc-os2/issues/14) that should not be related in any way here as no response files are used. I'm puzzled.