[Top][All Lists]

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

Re: [PATCH 1/2] Relocator framework

From: Robert Millan
Subject: Re: [PATCH 1/2] Relocator framework
Date: Fri, 7 Aug 2009 13:06:54 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]