On 05/02/2018 06:18 PM, Jan Kiszka wrote: > On 2018-05-02 16:51, Ralf Ramsauer wrote: >> >> >> On 05/01/2018 06:54 PM, Jan Kiszka wrote: >>> On 2018-05-01 10:54, Ralf Ramsauer wrote: >>>> On 04/27/2018 08:21 PM, Jan Kiszka wrote: >>>>> On 2018-04-27 11:36, Ralf Ramsauer wrote: >>>>>> This won't drop symbols that are marked as used. >>>>>> >>>>>> The static, relocateable inmate library lib.a is created by ar. When >>>>>> linking executables, unreferenced symbols may be dropped, even if they >>>>>> are attributed as used. >>>>>> >>>>>> --whole-archive ensures that those symbols will be linked. >>>>>> >>>>>> Whereas on x86, we need --gc-sections. >>>>> >>>>> That's something I do not understand yet: With [1] we will build the >>>>> whole hypervisor, including x86, with --whole-archive, and that works >>>>> fine on x86 as well. >>>> >>>> That's what happens if I compile x86 inmates with --whole-archive >>>> instead of --gc-sections: >>>> >>>> LD >>>> /home/ralf/workspace/jailhouse/inmates/demos/x86/32-bit-demo-linked.o >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/lib32.a(ioapic-32.o): In >>>> function `ioapic_init': >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/ioapic.c:48: undefined >>>> reference to `map_range' >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/lib32.a(smp-32.o): In >>>> function `smp_start_cpu': >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/smp.c:59: undefined >>>> reference to `delay_us' >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/smp.c:61: undefined >>>> reference to `delay_us' >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/lib32.a(pci-32.o): In >>>> function `pci_find_device': >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/../pci.c:47: undefined >>>> reference to `pci_read_config' >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/../pci.c:51: undefined >>>> reference to `pci_read_config' >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/lib32.a(pci-32.o): In >>>> function `pci_find_cap': >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/../pci.c:61: undefined >>>> reference to `pci_read_config' >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/../pci.c:65: undefined >>>> reference to `pci_read_config' >>>> /home/ralf/workspace/jailhouse/inmates/lib/x86/../pci.c:68: undefined >>>> reference to `pci_read_config' >>>> >>>> Interestingly, this only happens to the 32-bit demo inmate. >>>> >>> >>> Because we keep everything, something might be missing now: The 32-bit >>> lib does not provide support for all features that its big 64-bit >>> brother has. >>> >>> I still think this approach is too much of a big hammer. Try >>> --print-gc-sections on your specific problem (uart section loss) and >>> play with --undefined as suggested by the ld man page. Not sure if there >>> is also some linker script statement that can do that trick, but it >>> might be worth checking. >> >> KEEP, together with --whole-archive does the trick: >> > > Why still --whole-archive? We should have a clear reason here.
Doesn't work without --whole-archive, ld still drops it then. It's the combination of --whole-archive and KEEP() that makes it working for ARM on the one hand, and doesn't break the 32-bit x86 demo inmate on the other. I guess the reason is that KEEP() only keeps symbols that enter a 'final stage' of the linking process. And as those symbols are never referenced anywhere, they seem to be dropped before, like they never enter that stage of the process where they could be kept. See [1], 4.6.4.4: When link-time garbage collection is in use (-gc-sections), it is often useful to mark sections that should not be eliminated. This is accomplished by surrounding an input section's wildcard entry with KEEP(), as in KEEP(*(.init)) or KEEP(SORT(*)(.ctors)). BTW: I read that __attribute__((used)) never affects the linking process, it only forces the compiler to not optimize away unreferenced things during compilation. Ralf [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/sections.html > >> .uarts : { >> __uarts_array_start = .; >> KEEP(*(.uarts)); >> __uarts_array_end = .; >> } > > Yeah, there must have been some magic there... > > Jan > -- You received this message because you are subscribed to the Google Groups "Jailhouse" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
