On Fri, Apr 05, 2024 at 05:04:37AM +0000, Thorsten Glaser wrote: > Markus Wichmann dixit: > > >can check with readelf -r what the relocation types are. If they are not > >relative, they will not be processed. > > Gotcha! They are all R_390_RELATIVE except for: > > 000000045ff0 001100000016 R_390_64 0000000000042c58 u_ops + 70 > 000000045ff8 001100000016 R_390_64 0000000000042c58 u_ops + 0 > 000000047020 001100000016 R_390_64 0000000000042c58 u_ops + 80 > 000000047088 001100000016 R_390_64 0000000000042c58 u_ops + 80 > 0000000470a8 001100000016 R_390_64 0000000000042c58 u_ops + b8 > 000000047220 001100000016 R_390_64 0000000000042c58 u_ops + 80 > 000000046900 002600000016 R_390_64 0000000000015af8 c_command + 0 > 000000046940 000700000016 R_390_64 0000000000017238 c_exec + 0 > 000000046ab0 002000000016 R_390_64 0000000000016a80 c_trap + 0 > 000000047090 002500000016 R_390_64 00000000000430ac initvsn + 0 > 000000047278 005500000016 R_390_64 0000000000047438 null_string + 2 > > That’s our missing strings.
Is there anything weird about how these objects were declared that might have caused ld not to resolve them statically like it should? It seems odd that these data symbols, but not any other ones, would be left as symbolic relocations. Rich
