Re: [PATCH v4 2/4] xen: Add files needed for minimal ppc64le build

[Shawn Anastasio <sanastasio@xxxxxxxxxxxxxxxxxxxxx>]

On 6/19/23 11:07 AM, Jan Beulich wrote:
>> It seems like the build system expects an `$(ARCH)_defconfig` present if
>> you don't manually specify a defconfig target. I see riscv64 has a
>> tiny64_defconfig and a riscv64_defconfig that are idential, probably for
>> this same reason. Would you like me to take the same approach of
>> duplicating openpower_defconfig to ppc64_defconfig?
> 
> It's a symlink for RISC-V iirc, so wants to be that same way for PPC
> then (for the time being, again like there).

Ah, you're right, riscv uses a symlink. I'll use that approach here as
well then.

>> Good point. Following the example in the Power ELFv2 ABI
>> specification [1] for function type annotation, I'll place
>>
>> .type start, @function
>>
>> in the ENTRY macro. It's not clear what the difference between %function
>> and @function are in this context (my toolchain seems to accept both and
>> produce the same ELF metadata), but the latter is more idiomatic in
>> Power assembly. The same goes for its placement before the entrypoint
>> vs. after the last instruction.
> 
> % and @ are entirely the same here, except for targets like arm-*,
> where @ starts a comment.

Okay, thanks for the confirmation. Is there a preference for which one
is used? I'd lean towards @ just for the sake of remaining idiomatic,
but since they're equivalent it doesn't really matter from my
perspective.

>> No plans on supporting dynamic relocation (for now), so I can go ahead
>> and add these assertions.
> 
> How would you ever use dynamic relocations? You have no loader to
> process them for you. (Yes, there can of course be relocation free
> head.S code which deals with relocations, but doing such in assembly
> is likely not the best idea. Yet as soon as you enter C code you're
> at risk of hitting a place requiring such a relocation, perhaps
> simply because of a "careless" function call on some infrequently
> used code path.)

Right, those concerns are definitely something we'd have to deal with if
we ever wanted to add support for relocations (and a large part of the
reason why I said I don't have plans to support it right now).

As an aside, I'll note that Linux uses the approach of doing the
relocation fixups entirely in assembly before the C entrypoint, but
that's obviously not a super desirable approach from a correctness or
maintainability standpoint.

> Jan

Thanks,
Shawn