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