Re: [PATCH 1/2] Relocator framework

[Robert Millan <rmh@aybabtu.com>]

On Wed, Aug 05, 2009 at 12:18:17PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >> +#ifdef __x86_64__
> >> +extern grub_uint64_t grub_relocator32_backward_src;
> >> +#else
> >> +extern grub_uint32_t grub_relocator32_backward_src;
> >> +#endif
> >
> > You could make this a pointer, or grub_uintptr_t
> > (the latter we don't yet have, it seems like a good excuse to
> > add it if a pointer is not suitable :-)).
> grub_addr_t would actually do the job.

Ah yes, of course.

> > Are you sure moving to movsl is a good idea?  Maybe the payload size is not
> > 4-aligned.
> >
> On AFAIK x86 movsl works on unaligned addresses too. I'll recheck

But maybe there's some corner case in which we would overwrite something if
we copy 3 bytes more than necessary?  I didn't check if this would be possible.

> >> +#ifdef APPLE_CC
> >> +     add $(cont0 - base), %eax
> >> +#else
> >> +     add $(cont0 - base), %rax
> >> +#endif
> >
> > What's the issue at hand?  Apple assembler [1] can't add an inmediate to
> > %rax ?
> >
> Apple linker can't handle 64-bit differences

This seems like a bug.  Can GNU binutils be used on MacOS to resolve this?

If it's workable, I'd rather make binutils a build requirement than adding
more of this (the other APPLE_CC ifdefs will probably need some review too,
but there's no hurry about that).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."