Simulator bootloader fails with gcc 4

Simulator bootloader fails with gcc 4

[Ian Wienand]

Hi,

After building a fresh tree with gcc 4 I can't boot the simulator as
the bootloader loader dies with 

loading /home/ianw/kerntest/kerncomp//build/sim_defconfig/vmlinux...
failed to read phdr

After some investigation I believe this is do with differences between
the alignment of variables on the stack between gcc 3 and 4 and the
ski simulator.  If you trace through with the simulator you can see
that the disk_stat structure value returned from the
SSC_WAIT_COMPLETION call seems to be only half loaded.  I guess it
doesn't like the alignment of the input.  I confirmed that things do
get aligned differently thusly :

ianw@lime:/tmp$ cat test.c
#include <stdio.h>

struct disk_stat {
        int fd;
        unsigned count;
};

int main(void)
{
        int blah;
        struct disk_stat test;

        printf("%p\n", &test);
}
ianw@lime:/tmp$ gcc-3.4 -o test test.c
ianw@lime:/tmp$ ./test
0x60000fffffc2f480
ianw@lime:/tmp$ gcc-4.0 -o test test.c
ianw@lime:/tmp$ ./test
0x60000fffff813484

The patch below at least fixes it for me.

Thanks,

-i

Signed-Off-By: Ian Wienand <ianw@gelato.unsw.edu.au>

--

diff --git a/arch/ia64/hp/sim/boot/bootloader.c b/arch/ia64/hp/sim/boot/bootloader.c
--- a/arch/ia64/hp/sim/boot/bootloader.c
+++ b/arch/ia64/hp/sim/boot/bootloader.c
@@ -33,7 +33,7 @@ struct disk_req {
 struct disk_stat {
 	int fd;
 	unsigned count;
-};
+} __attribute__ ((aligned (16)));
 
 extern void jmp_to_kernel (unsigned long bp, unsigned long e_entry);
 extern struct ia64_boot_param *sys_fw_init (const char *args, int arglen);

Re: Simulator bootloader fails with gcc 4

[James E Wilson]

On Tue, 2005-07-19 at 22:31, Ian Wienand wrote:
> After some investigation I believe this is do with differences between
> the alignment of variables on the stack between gcc 3 and 4 and the
> ski simulator.

There has been no change to the natural alignment for the variable
here.  It has always been 4 bytes.  There has been a change to the
placement of variables into stack slots.  This stuff was completely
written as part of the tree-ssa work.

If gcc-3.4 and earlier, some structures (BLKmode structures) were being
over-aligned when allocated to stack slots.  They always got the maximum
alignment (16 bytes for IA-64) instead of their natural alignment.  It
isn't clear why.  I think this was an accident of implementation.  We
were basing variable alignment on modes instead of type alignment, and
since some BLKmode structures do require max alignment, we had to give
it to all of them.

In gcc-4.0, we get this right.  The variable/type alignment is used to
determine the stack alignment needed.  If the alignment is less than the
stack slot size, then we don't pad to the next stack slot regardless of
the size or type or mode of the variable.  We only pad to the alignment
boundary.  This results in smaller frame sizes.  In this case though, we
end up with the structure being allocated across two stack slots, even
though it would fit in one.  Again, I think this is an accident of
implementation.  We might get better code if this structure was
allocated to a single stack slot, as then we could use ld8/st8 to move
it around.  This would be at the expense of a small increase in frame
size in general, though we would still have smaller frames than gcc-3.4
and earlier.  Probably no one has considered this issue because no one
has noticed it before.

Re: Simulator bootloader fails with gcc 4

[Ian Wienand]

[-- Attachment #1: Type: text/plain, Size: 333 bytes --]

On Wed, Jul 20, 2005 at 03:31:39PM +1000, Ian Wienand wrote:
> After some investigation I believe this is do with differences between
> the alignment of variables on the stack between gcc 3 and 4 and the
> ski simulator.

For tracking purposes I've put this in the gcc bugzilla

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22605

-i

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Simulator bootloader fails with gcc 4

[david mosberger]

On 7/21/05, Ian Wienand <ianw@gelato.unsw.edu.au> wrote:
> On Wed, Jul 20, 2005 at 03:31:39PM +1000, Ian Wienand wrote:
> > After some investigation I believe this is do with differences between
> > the alignment of variables on the stack between gcc 3 and 4 and the
> > ski simulator.
> 
> For tracking purposes I've put this in the gcc bugzilla
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id"605

Regardless of what GCC is doing, this seems to be a ski bug.  I no
longer have access to the Ski sources, so there is nothing I can do. 
Dan, do you want to take a quick look to see if anything obvious is
wrong in that area?

  --david
-- 
Mosberger Consulting, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane                                                    
        Fremont, CA 94536

Re: Simulator bootloader fails with gcc 4

[Ian Wienand]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

On Thu, Jul 21, 2005 at 11:00:56PM -0700, david mosberger wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22605

> Dan, do you want to take a quick look to see if anything obvious is
> wrong in that area?

Did anyone end up deciding if the kernel or the simulator should be
fixed?  I'd like the simulator autobuild to "just work" with gcc4
without having to copy in an old bootloader or something.

-i

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Simulator bootloader fails with gcc 4

[Luck, Tony]

>On Thu, Jul 21, 2005 at 11:00:56PM -0700, david mosberger wrote:
>> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id"605
>
>> Dan, do you want to take a quick look to see if anything obvious is
>> wrong in that area?
>
>Did anyone end up deciding if the kernel or the simulator should be
>fixed?  I'd like the simulator autobuild to "just work" with gcc4
>without having to copy in an old bootloader or something.

And behind door number 3 is to fix the compiler ... but that also
seems to be contentious (and doesn't help people who are already
using gcc4).

Is the simulator in error by only half loading when the structure
is on a 4-byte boundary ... if so, then my 2nd choice would be to
fix it there.

But ... since the fix is small, I could put it into the kernel
as a last resort to get things working again.  Do you really need
to align(16)? Or would (8) do?  A comment mentioning that this
is a workaround for a compiler and/or simulator issue would be
good.

-Tony

Re: Simulator bootloader fails with gcc 4

[Ian Wienand]

On Tue, Aug 16, 2005 at 03:46:47PM -0700, Luck, Tony wrote:
> And behind door number 3 is to fix the compiler ... but that also
> seems to be contentious (and doesn't help people who are already
> using gcc4).

I really wouldn't know where to start making the changes James
suggested, but if someone wants some help with running some benchmarks
or some hardware, I can help there.
 
> Is the simulator in error by only half loading when the structure
> is on a 4-byte boundary ... if so, then my 2nd choice would be to
> fix it there.

<squeaky wheel> HP, please give us the source for SKI </squeaky
wheel>. :)

> But ... since the fix is small, I could put it into the kernel
> as a last resort to get things working again.  Do you really need
> to align(16)? Or would (8) do?  A comment mentioning that this
> is a workaround for a compiler and/or simulator issue would be
> good.

It seems to want 16, 8 causes the same problem.  Below includes a
small comment.

Thanks,

-i

diff --git a/arch/ia64/hp/sim/boot/bootloader.c b/arch/ia64/hp/sim/boot/bootloader.c
--- a/arch/ia64/hp/sim/boot/bootloader.c
+++ b/arch/ia64/hp/sim/boot/bootloader.c
@@ -30,10 +30,14 @@ struct disk_req {
 	unsigned len;
 };
 
+/* SSC_WAIT_COMPLETION appears to want this large alignment.  gcc < 4
+ * seems to give it by default, however gcc > 4 is smarter and may
+ * not.
+ */
 struct disk_stat {
 	int fd;
 	unsigned count;
-};
+} __attribute__ ((aligned (16)));
 
 extern void jmp_to_kernel (unsigned long bp, unsigned long e_entry);
 extern struct ia64_boot_param *sys_fw_init (const char *args, int arglen);

Re: Simulator bootloader fails with gcc 4

[Stephane Eranian]

Ian,

On Thu, 2005-08-18 at 10:53 +1000, Ian Wienand wrote:
> On Tue, Aug 16, 2005 at 03:46:47PM -0700, Luck, Tony wrote:
> > And behind door number 3 is to fix the compiler ... but that also
> > seems to be contentious (and doesn't help people who are already
> > using gcc4).
> 
> I really wouldn't know where to start making the changes James
> suggested, but if someone wants some help with running some benchmarks
> or some hardware, I can help there.
>  
> > Is the simulator in error by only half loading when the structure
> > is on a 4-byte boundary ... if so, then my 2nd choice would be to
> > fix it there.
> 
> <squeaky wheel> HP, please give us the source for SKI </squeaky
> wheel>. :)
> 
Unfortunately, this is not just my decision. 

Anyway, I looked quickly at the simulator code. I don't see anything
wrong on that side. On SSC_COMPLETION, you end up doing a byte by byte
memcpy for copyin for disk_stat and a byte by byte for copyout. Not much
could go wrong there. The definition for disk_stat is identical (w/o the
aligned attribute).

> > But ... since the fix is small, I could put it into the kernel
> > as a last resort to get things working again.  Do you really need
> > to align(16)? Or would (8) do?  A comment mentioning that this
> > is a workaround for a compiler and/or simulator issue would be
> > good.
> 
> It seems to want 16, 8 causes the same problem.  Below includes a
> small comment.
> 

If the small patch below fixes the problem, this should be the way
to solve this. It does not hurt people not using gcc4.


> diff --git a/arch/ia64/hp/sim/boot/bootloader.c b/arch/ia64/hp/sim/boot/bootloader.c
> --- a/arch/ia64/hp/sim/boot/bootloader.c
> +++ b/arch/ia64/hp/sim/boot/bootloader.c
> @@ -30,10 +30,14 @@ struct disk_req {
>  	unsigned len;
>  };
>  
> +/* SSC_WAIT_COMPLETION appears to want this large alignment.  gcc < 4
> + * seems to give it by default, however gcc > 4 is smarter and may
> + * not.
> + */
>  struct disk_stat {
>  	int fd;
>  	unsigned count;
> -};
> +} __attribute__ ((aligned (16)));
>  
>  extern void jmp_to_kernel (unsigned long bp, unsigned long e_entry);
>  extern struct ia64_boot_param *sys_fw_init (const char *args, int arglen);
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Simulator bootloader fails with gcc 4

[Luck, Tony]

>Anyway, I looked quickly at the simulator code. I don't see anything
>wrong on that side. On SSC_COMPLETION, you end up doing a byte by byte
>memcpy for copyin for disk_stat and a byte by byte for copyout. Not much
>could go wrong there. The definition for disk_stat is identical (w/o the
>aligned attribute).

Ah ... but gcc has an unpleasant habit of inlining memcpy() calls.  This
is really annoying when you have taken the trouble to replace code
does a structure copy with an explicit call to memcpy() becuase
you know that one of the source or destination is unaligned, only
to have gcc generate some inline ld8/st8 instructions.

-Tony

Re: Simulator bootloader fails with gcc 4

[Stephane Eranian]

Tony,

On Thu, Aug 18, 2005 at 11:57:03AM -0700, Luck, Tony wrote:
> >Anyway, I looked quickly at the simulator code. I don't see anything
> >wrong on that side. On SSC_COMPLETION, you end up doing a byte by byte
> >memcpy for copyin for disk_stat and a byte by byte for copyout. Not much
> >could go wrong there. The definition for disk_stat is identical (w/o the
> >aligned attribute).
> 
> Ah ... but gcc has an unpleasant habit of inlining memcpy() calls.  This
> is really annoying when you have taken the trouble to replace code
> does a structure copy with an explicit call to memcpy() becuase
> you know that one of the source or destination is unaligned, only
> to have gcc generate some inline ld8/st8 instructions.

The simulator is not using the regular memcpy() routine it has its own
custom routine (which is not named memcpy).

-- 

-Stephane

Re: Simulator bootloader fails with gcc 4

[Peter Chubb]

>>>>> "Stephane" = Stephane Eranian <eranian@hpl.hp.com> writes:

Stephane> The simulator is not using the regular memcpy() routine it
Stephane> has its own custom routine (which is not named memcpy).

This is a stupid suggestion, but...

     Can you try recompiling the simulator with gcc 4.0, and see if
     the problem is still there?  If a gcc 4.0-compiled simulator that
     fixes the problem, and still allows booting of kernels compiled
     with icc, gcc-2.96, etc., etc., can be released, then we're done.

-- 
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: Simulator bootloader fails with gcc 4

[Stephane Eranian]

On Fri, Aug 19, 2005 at 09:14:56AM +1000, Peter Chubb wrote:
> >>>>> "Stephane" = Stephane Eranian <eranian@hpl.hp.com> writes:
> 
> Stephane> The simulator is not using the regular memcpy() routine it
> Stephane> has its own custom routine (which is not named memcpy).
> 
> This is a stupid suggestion, but...
> 
>      Can you try recompiling the simulator with gcc 4.0, and see if
>      the problem is still there?  If a gcc 4.0-compiled simulator that
>      fixes the problem, and still allows booting of kernels compiled
>      with icc, gcc-2.96, etc., etc., can be released, then we're done.
> 
Does this problem happen with the x86 and/or ia64 ski version when bootloader
is compiled with gcc-4.0?

I can certainly try to compile ski with gcc-4.0. Could anyone of you
send me his .config file to make sure we have comparable kernels.

Thanks.


-- 
-Stephane

Re: Simulator bootloader fails with gcc 4

[Peter Chubb]

>>>>> "Stephane" = Stephane Eranian <eranian@hpl.hp.com> writes:

Stephane> On Fri, Aug 19, 2005 at 09:14:56AM +1000, Peter Chubb wrote:
>> >>>>> "Stephane" = Stephane Eranian <eranian@hpl.hp.com> writes:
>> 
Stephane> The simulator is not using the regular memcpy() routine it
Stephane> has its own custom routine (which is not named memcpy).
>>  This is a stupid suggestion, but...
>> 
>> Can you try recompiling the simulator with gcc 4.0, and see if the
>> problem is still there?  If a gcc 4.0-compiled simulator that fixes
>> the problem, and still allows booting of kernels compiled with icc,
>> gcc-2.96, etc., etc., can be released, then we're done.
>> 
Stephane> Does this problem happen with the x86 and/or ia64 ski
Stephane> version when bootloader is compiled with gcc-4.0?

IA64 and i386.

Stephane> I can certainly try to compile ski with gcc-4.0. Could
Stephane> anyone of you send me his .config file to make sure we have
Stephane> comparable kernels.

It's the arch/ia64/confis/sim_defconfig file in any recent kernel.

-- 
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

Re: Simulator bootloader fails with gcc 4

[Stephane Eranian]

Hello,

So I spent some time investigating the booloader
problem with ski and gcc-4.0. I think I found the source
of the problem. The fix from Ian is not solving the problem
it is simply masking it.

The reason the SSC_WAIT_COMPLETION fails is because
the file descriptor being passed is wrong (0 instead of 3).

The reason why it is wrong is because it gets somehow overwritten
by the SSC_READ call. The bootloader works is you reload stat.fd
after the SSC_READ. 

The question becomes why is the stat structure overwritten?

I ran my tests using on I386 gcc-4.0 comiled ski. For
some reason gcc-4.0 dies compiling ski on IA-64.

On i386 ski, I noticed that due to alignment constraints
the disk_req structure as used by the bootloader has
a size of 16 bytes whereas on i386 ski the same structure
as a size of 12. Extra padding at the end o the struct
is added on Ia-64. This does not affect that particular
SSC_READ call we have in the bootloader because we only
pass 1 disk_req struct. Passing more than one would
systematically fail because the simulator is walking
the disk_req structure using += sizeof(disk_req). I think
this is a lurking problem that should somehow be fixed.

The real problem for the stat structure is that it gets
overwritten by the mem[] array and not disk_req. I added
some debug printf to the simulator and looked at the symbol
table for the bootloader. The mem[] array is static.
The disk_stat is allocated on the stack, I think. Now
with gcc-4.0 the mem[] array overlaps the disk_stat!

$ nm bootloader.gcc4 | fgrep mem
0000000000105410 b mem

The mem array is 4096, so it ends at 0x106410.
The ski trace shows that the SSC_WAIT_COMPLETION
disk_stat address is 0x106400. They overlap by 16 bytes!

I don't know what this is, looks like gcc-4.0 has a 
problem with the code in bootloader.c.

I used Debian/ia64 testing gcc-4.0: version 4.0.1 (Debian 4.0.1-2)
I used binutils Debian/ia64 testing 2.16.1

Hope this can help you track this down some more.

On Fri, Aug 19, 2005 at 09:58:16AM +1000, Peter Chubb wrote:
> >>>>> "Stephane" = Stephane Eranian <eranian@hpl.hp.com> writes:
> 
> Stephane> On Fri, Aug 19, 2005 at 09:14:56AM +1000, Peter Chubb wrote:
> >> >>>>> "Stephane" = Stephane Eranian <eranian@hpl.hp.com> writes:
> >> 
> Stephane> The simulator is not using the regular memcpy() routine it
> Stephane> has its own custom routine (which is not named memcpy).
> >>  This is a stupid suggestion, but...
> >> 
> >> Can you try recompiling the simulator with gcc 4.0, and see if the
> >> problem is still there?  If a gcc 4.0-compiled simulator that fixes
> >> the problem, and still allows booting of kernels compiled with icc,
> >> gcc-2.96, etc., etc., can be released, then we're done.
> >> 
> Stephane> Does this problem happen with the x86 and/or ia64 ski
> Stephane> version when bootloader is compiled with gcc-4.0?
> 
> IA64 and i386.
> 
> Stephane> I can certainly try to compile ski with gcc-4.0. Could
> Stephane> anyone of you send me his .config file to make sure we have
> Stephane> comparable kernels.
> 
> It's the arch/ia64/confis/sim_defconfig file in any recent kernel.
> 
> -- 
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
> The technical we do immediately,  the political takes *forever*

-- 

-Stephane

Re: Simulator bootloader fails with gcc 4

[Peter Chubb]

>>>>> "Stephane" = Stephane Eranian <eranian@hpl.hp.com> writes:

Stephane> Hello, So I spent some time investigating the booloader
Stephane> problem with ski and gcc-4.0. I think I found the source of
Stephane> the problem. The fix from Ian is not solving the problem it
Stephane> is simply masking it.

Stephane> The real problem for the stat structure is that it gets
Stephane> overwritten by the mem[] array and not disk_req. I added
Stephane> some debug printf to the simulator and looked at the symbol
Stephane> table for the bootloader. The mem[] array is static.
Stephane> The disk_stat is allocated on the stack, I think. Now
Stephane> with gcc-4.0 the mem[] array overlaps the disk_stat!

Take a look at this code from boot_head.S:

    
    .bss
    .align 16
stack_mem:
    .skip 16834

GLOBAL_ENTRY(_start)
	.prologue
	.save rp, r0
	.body
	movl gp = __gp
	movl sp = stack_mem
	bsw.1
	br.call.sptk.many rp=start_bootloader
END(_start)

Doesn't the stack grow downwards on IA64? Shouldn't that be something
like:

	.bss
	.align 16
rbs_mem:
	skip 18384-16
stack_mem:
	skip 16

????

I can't run ski at present to check it (it segfaults immediately)

Peter C

Re: Simulator bootloader fails with gcc 4

[Stephane Eranian]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

Peter,

> 
>     
>     .bss
>     .align 16
> stack_mem:
>     .skip 16834
> 
> GLOBAL_ENTRY(_start)
> 	.prologue
> 	.save rp, r0
> 	.body
> 	movl gp = __gp
> 	movl sp = stack_mem
> 	bsw.1
> 	br.call.sptk.many rp=start_bootloader
> END(_start)
> 
> Doesn't the stack grow downwards on IA64? Shouldn't that be something
> like:

The memory stack grows down, the RBS grows up.

> 
> 	.bss
> 	.align 16
> rbs_mem:
> 	skip 18384-16
> stack_mem:
> 	skip 16
> 
> ????
> 
Ok, this change seems to work for both gcc-4.0 and gcc-3.3.5. So what this is saying
is that we got lucky with the older compilers that the variables were somehow laid out
slightly differently on the stack.

> I can't run ski at present to check it (it segfaults immediately)
> 
Well, that will be the next thing I need to check. It dies on both IA64 and I386?

The attached patch fixes the bootloader problem for me.

-- 

-Stephane

[-- Attachment #2: bootloader-050819.diff --]
[-- Type: text/plain, Size: 307 bytes --]

--- arch/ia64/hp/sim/boot/boot_head.S.orig      2005-08-19 16:40:20.000000000 -0700
+++ arch/ia64/hp/sim/boot/boot_head.S   2005-08-19 16:40:25.000000000 -0700
@@ -7,8 +7,10 @@

        .bss
        .align 16
+rbs_mem:
+       .skip 18384-16
 stack_mem:
-       .skip 16834
+       .skip 16

        .text

Re: Simulator bootloader fails with gcc 4

[Peter Chubb]

>>>>> "Stephane" = Stephane Eranian <eranian@hpl.hp.com> writes:

Stephane> Peter,
Stephane> Ok, this change seems to work for both gcc-4.0 and
Stephane> gcc-3.3.5. So what this is saying is that we got lucky with
Stephane> the older compilers that the variables were somehow laid out
Stephane> slightly differently on the stack.

>> I can't run ski at present to check it (it segfaults immediately)
>> 
Stephane> Well, that will be the next thing I need to check. It dies
Stephane> on both IA64 and I386?

Well, yes and no.

on IA64 it segfaults.  On IA32, I get `can't open console window',
because Ski appears to be passing a FD that's closed to xterm.
(It invokes xterm with -S/63 but fd 63 isn't open --- only fds 0, 1, 2
and 4, so xterm dies with:

Linux/ia64 Console: Error 12, errno 9: Bad file descriptor
Reason: main: ioctl() failed on F_GETFL


-- 
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
The technical we do immediately,  the political takes *forever*

RE: Simulator bootloader fails with gcc 4

[Gerald Pfeifer]

Tony,

On Thu, 18 Aug 2005, Luck, Tony wrote:
> Ah ... but gcc has an unpleasant habit of inlining memcpy() calls.  This
> is really annoying when you have taken the trouble to replace code
> does a structure copy with an explicit call to memcpy() becuase
> you know that one of the source or destination is unaligned, only
> to have gcc generate some inline ld8/st8 instructions.

have you considered using one of the following options in some of these
cases?

  `-fno-builtin-FUNCTION'
      Don't recognize built-in functions that do not begin with
      `__builtin_' as prefix.

  `-mmemcpy'
  `-mno-memcpy'
      The `-mmemcpy' switch makes all block moves call the appropriate
      string function (`memcpy' or `bcopy') instead of possibly
      generating inline code.

(I'm currently offline and only have GCC 3.3 docs available, but I'm
pretty sure GCC 3.4 and 4.x support these as well.)

Gerald

Re: Simulator bootloader fails with gcc 4

[Andreas Schwab]

Gerald Pfeifer <gp@suse.de> writes:

>   `-mmemcpy'
>   `-mno-memcpy'
>       The `-mmemcpy' switch makes all block moves call the appropriate
>       string function (`memcpy' or `bcopy') instead of possibly
>       generating inline code.

All -m* options are target dependent, and ia64 does not have such an
option.  In fact, this option only exists on MIPS targets.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."