[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to support the Debian Sparc64 Port

Hi Gregor!

On 11/27/19 8:43 AM, Gregor Riepl wrote:
>> User: debian-sparc@lists.debian.org Usertags: sparc64 X-Debbugs-CC:
>> debian-sparc@lists.debian.org
> Bug reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945414
> Upstream bug: https://gitlab.gnome.org/GNOME/gcr/issues/34
> I also included a patch and submitted a PR upstream.

Perfect, thanks. This is exactly how it is supposed to be done and how people
are providing valuable support to Debian Ports. Thank you!

> In case this takes a long time to commit or is rejected upstream, is there a
> way to have a patched version only for Debian sparc64?

You can attach the patch to the Debian bug report, add the tag "patch" to the bug
report and hope that the maintainer will add the patch. We could also build the
package locally and upload it to "unreleased" but that would get overridden every
time a new package version gets uploaded by the maintainer.

I think you should give it a try to ask the gcr maintainer in Debian to include
your patch. With your explanation about the optimization below, I think chances
are pretty good.

> While investigating the problem, I was surprised to find the the memcpy is
> completely optimised out on amd64. It compiles into a simple MOV instruction,
> just like with pointer aliasing. On sparc64, we get a memcpy call.

Yeah, gcc has become really good at optimizing code with gcc-9.

> AFAIK x86/amd64 processors do generate alignment faults on unaligned 64-bit
> memory access - is there something different about the allocated memory, or is
> this handled silently by the kernel somehow?

Do they really? I always thought on x86, unaligned is not a problem at all,
neither for performance reasons nor by raising traps. There are only exceptions
with certain SSE instructions which need proper alignment as far as I know.

Other architectures do profit from better alignment though and I think with
the knowledge that gcc will optimize memcpy when it's not necessary, you have
a very good argument why such patches should be merged.


 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply to: