|
From: Nicholas N. <nj...@ca...> - 2004-07-27 14:08:47
|
Hi, I'm making progress on x86-64; I've discovered that the calling conventions for functions and system calls are totally different than for x86... ABI documents are useful :) Anyway, I'm getting a strange error. stage1 is successfully starting stage2, but then bad things are happening. The problem is that some of the VG_(clo_*) arguments are initialised to the right values, but some of them are being initialised to totally bogus values. Here's some debugging output -- for each variable I print the name, its address, the value it is initialised to in the code, and then the actual value it gets at run-time. ---------------------------------------- stage2 main! ---------------------------------------- VG_(clo_error_limit) 0x601b03dd = True; 1 VG_(clo_db_command) 0x601b03e0 = VG_CLO_DEFAULT_DBCOMMAND; /usr/bin/gdb -nw %f %p VG_(clo_sanity_level) 0x601b03e8 = 1; 1 VG_(clo_verbosity) 0x601b03ec = 1; 1 VG_(clo_demangle) 0x601b03f0 = True; 1 VG_(clo_trace_children) 0x601bd8ae = False; 0 VG_(clo_log_fd) 0x601b03f4 = 1; 1 VG_(clo_suppressions)[] 0x602f19c0 = ?; 0x602f19c0 VG_(clo_optimise) 0x601b03f8 = True; 1 VG_(clo_trace_codegen) 0x601bd8ca = 0; // 00000000b 0 VG_(clo_trace_syscalls) 0x601bd8cb = False; 0 VG_(clo_backtrace_size) 0x601b03fc = 4; 4 VG_(clo_run_libc_freere)0x601b0400 = True; 1 VG_(clo_track_fds) 0x601bd8e0 = False; 0 VG_(clo_chain_bb) 0x601b0401 = True; 1 VG_(clo_pointercheck) 0x601b0402 = True; 1 ---- VG_(clo_db_attach) 0x601bd8ac = False; 16 VG_(clo_gen_suppression)0x601bd8ad = False; 51 VG_(clo_log_to) 0x601bd8b0 = VgLogTo_Fd; 992843285 VG_(clo_log_name) 0x601bd8b8 = NULL; 0x9715000034210758 VG_(clo_input_fd) 0x601bd8c0 = 0; /* stdin */ 15149 VG_(clo_n_suppressions) 0x601bd8c4 = 0; 124265218 VG_(clo_profile) 0x601bd8c8 = False; 209 VG_(clo_single_step) 0x601bd8c9 = False; 26 VG_(clo_trace_signals) 0x601bd8cc = False; 21 VG_(clo_trace_symtab) 0x601bd8cd = False; 164 VG_(clo_trace_sched) 0x601bd8ce = False; 203 VG_(clo_trace_pthread_level) 0x601bd8d0 = 0; 587333632 VG_(clo_dump_error) 0x601bd8d4 = 0; -1828585352 VG_(clo_weird_hacks) 0x601bd8d8 = NULL; 0xd54516000021 VG_(clo_show_below_main)0x601bd8e1 = False; 2 VG_(clo_branchpred) 0x601bd8e2 = False; 154 Those in the top half are correctly initialised to the value specified in the code. Those in the bottom half are getting bogus values. The bogus values are bogus from the very moment they are mapped into memory, in mapelf(). (I checked this with a hexdump of the just-mapped-in code in mapelf()) The interesting thing is that all the bogus ones are in one memory area around 0x601bd8a0, but most of the correct ones are in a different memory area around 0x601b03d8. (Some of the correct ones have similar addresses to the bogus ones... these are mostly meant to be 0, eg. VG_(clo_trace_children), so they are probably bogus but just getting the right value by chance.) I've used readelf to look at stage2 and the variable addresses do seem to be correct, so that's no help. I'm stumped... can anyone see what might be happening here? I'm highly suspicious of the variables being put in two different memory locations. If it's any use, the equivalent dump for x86 is below; for it the variables aren't partitioned into two different areas, and they are (not surprisingly) all correct. ---------------------------------------- stage2 main! ---------------------------------------- VG_(clo_error_limit) 0xb00826b8 = True; 1 VG_(clo_db_command) 0xb00826bc = VG_CLO_DEFAULT_DBCOMMAND; /usr/bin/gdb -nw %f %p VG_(clo_sanity_level) 0xb00826c4 = 1; 1 VG_(clo_verbosity) 0xb00826c8 = 1; 1 VG_(clo_demangle) 0xb00826cc = True; 1 VG_(clo_trace_children) 0xb00826cd = False; 0 VG_(clo_log_fd) 0xb00826d4 = 1; 1 VG_(clo_suppressions)[] 0xb01b2420 = ?; 0xb01b2420 VG_(clo_optimise) 0xb00826e6 = True; 1 VG_(clo_trace_codegen) 0xb00826e7 = 0; // 00000000b 0 VG_(clo_trace_syscalls) 0xb00826e8 = False; 0 VG_(clo_backtrace_size) 0xb00826f4 = 4; 4 VG_(clo_run_libc_freere)0xb00826fc = True; 1 VG_(clo_track_fds) 0xb00826fd = False; 0 VG_(clo_chain_bb) 0xb00826fe = True; 1 VG_(clo_pointercheck) 0xb0082700 = True; 1 ---- VG_(clo_db_attach) 0xb00826b9 = False; 0 VG_(clo_gen_suppression)0xb00826c0 = False; 0 VG_(clo_log_to) 0xb00826d0 = VgLogTo_Fd; 0 VG_(clo_log_name) 0xb00826d8 = NULL; (nil) VG_(clo_input_fd) 0xb00826dc = 0; /* stdin */ 0 VG_(clo_n_suppressions) 0xb00826e0 = 0; 0 VG_(clo_profile) 0xb00826e4 = False; 0 VG_(clo_single_step) 0xb00826e5 = False; 0 VG_(clo_trace_signals) 0xb00826e9 = False; 0 VG_(clo_trace_symtab) 0xb00826ea = False; 0 VG_(clo_trace_sched) 0xb00826eb = False; 0 VG_(clo_trace_pthread_level) 0xb00826ec = 0; 0 VG_(clo_dump_error) 0xb00826f0 = 0; 0 VG_(clo_weird_hacks) 0xb00826f8 = NULL; (nil) VG_(clo_show_below_main)0xb00826ff = False; 0 VG_(clo_branchpred) 0xb0082701 = False; 0 I can tar up my current workspace and put it on my website if that would be useful. Thanks. N |
|
From: Bob F. <bfr...@si...> - 2004-07-27 14:15:37
|
On Tue, 27 Jul 2004, Nicholas Nethercote wrote: > > I can tar up my current workspace and put it on my website if that would be > useful. Why not just create a CVS development branch to support the x86-64 port? Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 15:01:39
|
On Tue, 27 Jul 2004, Nicholas Nethercote wrote: > I'm stumped... can anyone see what might be happening here? I'm highly > suspicious of the variables being put in two different memory locations. Hmm, I just had the idea of running stage2 stand-alone, rather than launching it with stage1 as normal. The bogus-value problem went away, so it's definitely caused by stage1 somehow... N |
|
From: Tom H. <th...@cy...> - 2004-07-27 17:19:12
|
In message <109...@ix...>
Jeremy Fitzhardinge <je...@go...> wrote:
> Looks like mapelf isn't respecting the alignment in the PHDR. What does
> readelf -l stage2 say?
It looks like it respects it to me.
> I bet the distinction between the groups of values is that some are
> initialized in the source, and some are not (ie, expected to default to
> 0/NULL).
I think this may be the problem - the code to zero pad from filesz
to memsz looks highly odd to me. Specifically where it works out the
value of "bytes" which is the amount of memory it zeros.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-07-27 17:33:28
Attachments:
valgrind-align-patch
|
In message <8e1...@lo...>
Tom Hughes <th...@cy...> wrote:
> In message <109...@ix...>
> Jeremy Fitzhardinge <je...@go...> wrote:
>
> > I bet the distinction between the groups of values is that some are
> > initialized in the source, and some are not (ie, expected to default to
> > 0/NULL).
>
> I think this may be the problem - the code to zero pad from filesz
> to memsz looks highly odd to me. Specifically where it works out the
> value of "bytes" which is the amount of memory it zeros.
This is the problem, and it is alignment related. When the odd bit
at the end of the mapping from the file is zero filled it only fills
up to the next page boundary instead of up to the alignment boundary
given in the header.
On x86-32 it happens to work because the alignment in the header is
normally the same as the page size, but x86-64 seems to be using an
alignment of 1Mb for some reason.
The attached patch should fix it.
That said, the map output that Nick sent from when stage2 was launched
directly makes it look like the OS was only round to page boundaries
anyway!
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 18:50:46
|
On Tue, 27 Jul 2004, Tom Hughes wrote: >> That said, the map output that Nick sent from when stage2 was launched >> directly makes it look like the OS was only round to page boundaries >> anyway! > > This patch may be better - it switches mapelf to do what the kernel > does and only map the pages that are required instead of rounding > everything to the specified alignment. > > It does assert that the overall result has the correct aligment > and will I think mean that the mapping of stage2 when launched by > stage1 will match the mapping when it is launched directly. Thanks Tom, this fixes the problem! (And it now falls over slightly further along :) I had worked out that Valgrind was observing the requested 0x100000 alignment and the kernel wasn't, but hadn't got any further than that. The kernel's behaviour seems odd here... Am I right that this second patch completely obsoletes the first? N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 19:06:21
|
On Tue, 27 Jul 2004, Tom Hughes wrote: >> Thanks Tom, this fixes the problem! (And it now falls over slightly >> further along :) I had worked out that Valgrind was observing the >> requested 0x100000 alignment and the kernel wasn't, but hadn't got any >> further than that. The kernel's behaviour seems odd here... Actually, when not using --help (as I was) although the bogus-initialisation problem is fixed, it asserts when loading the client: valgrind: ume.c:364: mapelf: Assertion `((addr - off) & (align - 1)) == 0' failed. The relevant values are: addr = 0x1ff27000, off = 0, align = 100000 ? N |
|
From: Jeremy F. <je...@go...> - 2004-11-30 18:41:51
|
On Tue, 2004-11-30 at 18:30 +0000, Tom Hughes wrote: > It wasn't checked in, but Nick had it in his x86-64 build. > > The problem is/was that although the ELF file has a 1Mb alignment > specified the kernel still only maps the pages that are needed - it > doesn't round the mapping to a 1Mb alignment as I recall. So the alignment only applies to the vaddr, not the memsize? In order to get the alignment, we'd need to mmap memsize+alignment-1 pages memory, and unmap the unneeded parts anyway, so trimming the mapping shouldn't be too hard. J |
|
From: Tom H. <th...@cy...> - 2004-11-30 18:56:39
|
In message <1101840108.4125.9.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Tue, 2004-11-30 at 18:30 +0000, Tom Hughes wrote:
> > It wasn't checked in, but Nick had it in his x86-64 build.
> >
> > The problem is/was that although the ELF file has a 1Mb alignment
> > specified the kernel still only maps the pages that are needed - it
> > doesn't round the mapping to a 1Mb alignment as I recall.
>
> So the alignment only applies to the vaddr, not the memsize?
> In order to get the alignment, we'd need to mmap memsize+alignment-1
> pages memory, and unmap the unneeded parts anyway, so trimming the
> mapping shouldn't be too hard.
You probably understand how it's all supposed to work better
than I do. As I recall we were trying to 1Mb each of sections
that we mapped while the kernel mapped them all as if the whole
file was 1Mb aligned. Or something like that - it was a while
ago now...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-07-27 15:05:30
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 27 Jul 2004, Nicholas Nethercote wrote:
>
>> I'm stumped... can anyone see what might be happening here? I'm
>> highly suspicious of the variables being put in two different memory
>> locations.
>
> Hmm, I just had the idea of running stage2 stand-alone, rather than
> launching it with stage1 as normal. The bogus-value problem went
> away, so it's definitely caused by stage1 somehow...
Given the address split between the two blocks of variables, have they
been put in separate sections in the ELF or something? Perhaps the
loader in stage1 isn't mapping the file right while the OS is?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 15:20:19
|
On Tue, 27 Jul 2004, Tom Hughes wrote: >> Hmm, I just had the idea of running stage2 stand-alone, rather than >> launching it with stage1 as normal. The bogus-value problem went >> away, so it's definitely caused by stage1 somehow... > > Given the address split between the two blocks of variables, have they > been put in separate sections in the ELF or something? Perhaps the > loader in stage1 isn't mapping the file right while the OS is? Yeah, when I launch via stage1 I see: 60000000-60100000 r-xp 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 60100000-60200000 rw-p 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 when I launch stage2 directly I see: 60000000-600b0000 r-xp 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 601b0000-601b1000 rw-p 000b0000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 which looks funny. I'll keep looking... N |
|
From: Jeremy F. <je...@go...> - 2004-07-27 16:41:38
|
On Tue, 2004-07-27 at 16:20 +0100, Nicholas Nethercote wrote: > On Tue, 27 Jul 2004, Tom Hughes wrote: > > >> Hmm, I just had the idea of running stage2 stand-alone, rather than > >> launching it with stage1 as normal. The bogus-value problem went > >> away, so it's definitely caused by stage1 somehow... > > > > Given the address split between the two blocks of variables, have they > > been put in separate sections in the ELF or something? Perhaps the > > loader in stage1 isn't mapping the file right while the OS is? > > Yeah, when I launch via stage1 I see: > > 60000000-60100000 r-xp 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 > 60100000-60200000 rw-p 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 > > when I launch stage2 directly I see: > > 60000000-600b0000 r-xp 00000000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 > 601b0000-601b1000 rw-p 000b0000 00:17 12063009 /auto/homes/njn25/grind/head6/coregrind/stage2 > > which looks funny. I'll keep looking... Looks like mapelf isn't respecting the alignment in the PHDR. What does readelf -l stage2 say? I bet the distinction between the groups of values is that some are initialized in the source, and some are not (ie, expected to default to 0/NULL). J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 18:51:55
|
On Tue, 27 Jul 2004, Jeremy Fitzhardinge wrote: > Looks like mapelf isn't respecting the alignment in the PHDR. What does > readelf -l stage2 say? Seems like mapelf was respecting it, but the kernel wasn't. Or something ilke that... > I bet the distinction between the groups of values is that some are > initialized in the source, and some are not (ie, expected to default to > 0/NULL). They are initialised explicitly in the code; it seems the compiler split them into zero and non-zero halves. Thanks for the help on this one. N |
|
From: Tom H. <th...@cy...> - 2004-07-27 18:21:09
Attachments:
valgrind-align2-patch
|
In message <ec6...@lo...>
Tom Hughes <th...@cy...> wrote:
> The attached patch should fix it.
>
> That said, the map output that Nick sent from when stage2 was launched
> directly makes it look like the OS was only round to page boundaries
> anyway!
This patch may be better - it switches mapelf to do what the kernel
does and only map the pages that are required instead of rounding
everything to the specified alignment.
It does assert that the overall result has the correct aligment
and will I think mean that the mapping of stage2 when launched by
stage1 will match the mapping when it is launched directly.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-07-27 18:56:27
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> Thanks Tom, this fixes the problem! (And it now falls over slightly
> further along :) I had worked out that Valgrind was observing the
> requested 0x100000 alignment and the kernel wasn't, but hadn't got any
> further than that. The kernel's behaviour seems odd here...
>
> Am I right that this second patch completely obsoletes the first?
Yes.
The first one should work, but you'll be mapping most if not
all of the BSS as copy-on-write pages which are then force to
be mapped by the memset instead of mapping them from /dev/zero
where they will only zpring into existence when used.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-07-27 20:01:14
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 27 Jul 2004, Tom Hughes wrote:
>
> >> Thanks Tom, this fixes the problem! (And it now falls over slightly
> >> further along :) I had worked out that Valgrind was observing the
> >> requested 0x100000 alignment and the kernel wasn't, but hadn't got any
> >> further than that. The kernel's behaviour seems odd here...
>
> Actually, when not using --help (as I was) although the
> bogus-initialisation problem is fixed, it asserts when loading the client:
>
> valgrind: ume.c:364: mapelf: Assertion `((addr - off) & (align - 1)) ==
> 0' failed.
>
> The relevant values are:
>
> addr = 0x1ff27000, off = 0, align = 100000
Does it work with the first patch? Come to that, does it work if
you just take out the assertion? I wasn't entirely sure that it was
the right assertion...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-27 20:07:34
|
On Tue, 27 Jul 2004, Tom Hughes wrote: > Does it work with the first patch? Come to that, does it work if > you just take out the assertion? I wasn't entirely sure that it was > the right assertion... Hard to say; just removing the assertion, it gets further before it falls over in the same way as it does for the -h case... N |
|
From: Nicholas N. <nj...@ca...> - 2004-07-28 08:20:28
|
On Tue, 27 Jul 2004, Bob Friesenhahn wrote: > Why not just create a CVS development branch to support the x86-64 port? Hmm... pros: - others can see it, try it easily cons: - keeping in sync with HEAD (ie. merging HEAD commits) is a pain - less flexibility, particularly with moving files around Does anyone have strong opinions either way? N |
|
From: Bob F. <bfr...@si...> - 2004-07-28 20:23:04
|
On Wed, 28 Jul 2004, Nicholas Nethercote wrote: > On Tue, 27 Jul 2004, Bob Friesenhahn wrote: > >> Why not just create a CVS development branch to support the x86-64 port? > > Hmm... > > pros: > - others can see it, try it easily > > cons: > - keeping in sync with HEAD (ie. merging HEAD commits) is a pain > - less flexibility, particularly with moving files around It doesn't seem all that important to keep in sync with the HEAD version (doing so is actually counter-productive) since the goal is to do the initial port. However, it seems that your work has been uncovering problems which should be addressed in the HEAD version. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Bob F. <bfr...@si...> - 2004-07-28 20:29:44
|
On Wed, 28 Jul 2004, Bob Friesenhahn wrote: > > It doesn't seem all that important to keep in sync with the HEAD version > (doing so is actually counter-productive) since the goal is to do the initial > port. However, it seems that your work has been uncovering problems which > should be addressed in the HEAD version. The reason why I say that keeping a development branch in sync with the HEAD version is counterproductive is that doing so makes the expected merge of the branch into HEAD much more difficult due to minor conflicts between the updates in both branches. However, if you can resist copying over fixes, doing the merge into the HEAD branch should take only a few minutes. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Nicholas N. <nj...@ca...> - 2004-11-29 18:36:06
|
Hi Tom, Do you remember this email from July, when I was working on the x86-64 port? On Tue, 27 Jul 2004, Tom Hughes wrote: >> The attached patch should fix it. >> >> That said, the map output that Nick sent from when stage2 was launched >> directly makes it look like the OS was only round to page boundaries >> anyway! > > This patch may be better - it switches mapelf to do what the kernel > does and only map the pages that are required instead of rounding > everything to the specified alignment. > > It does assert that the overall result has the correct aligment > and will I think mean that the mapping of stage2 when launched by > stage1 will match the mapping when it is launched directly. > > Tom (If you don't have the other mails in the thread still, I can forward them to you if it would help remind you about this.) I'm working on x86-64 again in the Subversion repo, and have reached this same point again. Do you think this patch is suitable for all architectures, ie. it should go into the SVN repo? An alternative way to write this patch is to just set 'align' to VKI_PAGE_SIZE. Thanks very much. N |
|
From: Tom H. <th...@cy...> - 2004-11-30 08:58:48
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Tue, 27 Jul 2004, Tom Hughes wrote:
>
>>> The attached patch should fix it.
>>>
>>> That said, the map output that Nick sent from when stage2 was launched
>>> directly makes it look like the OS was only round to page boundaries
>>> anyway!
>>
>> This patch may be better - it switches mapelf to do what the kernel
>> does and only map the pages that are required instead of rounding
>> everything to the specified alignment.
>>
>> It does assert that the overall result has the correct aligment
>> and will I think mean that the mapping of stage2 when launched by
>> stage1 will match the mapping when it is launched directly.
>
> Do you think this patch is suitable for all architectures, ie. it
> should go into the SVN repo?
Um. I'm not entirely sure which patch that was. I seem to have a
couple of patches lying around for alignment in ume.c so I guess
it was the later one.
As I recall all I did was try and mimic what the kernel ELF loader
does, which is platform independent code, so it should be fine for
all architectures as far as I know.
> An alternative way to write this patch is to just set 'align' to
> VKI_PAGE_SIZE.
Doesn't that mean we're ignoring the alignment in the ELF header?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Jeremy F. <je...@go...> - 2004-11-30 18:24:53
|
On Tue, 2004-11-30 at 08:58 +0000, Tom Hughes wrote: > > An alternative way to write this patch is to just set 'align' to > > VKI_PAGE_SIZE. > > Doesn't that mean we're ignoring the alignment in the ELF header? Yes. The original ume code assumed the ELF alignment was page size, but it seems that x86_64 uses a 1Mbyte alignment, even though its page size is 4k. Did you check in a fix for that, or just propose a fix? J |
|
From: Paul M. <pa...@sa...> - 2004-11-30 22:31:31
|
Jeremy Fitzhardinge writes: > Yes. The original ume code assumed the ELF alignment was page size, but > it seems that x86_64 uses a 1Mbyte alignment, even though its page size > is 4k. Did you check in a fix for that, or just propose a fix? I have a similar thing on ppc, where the ELF alignment is 64k, but the mappings are rounded to the page size. I believe the ELF alignment being N means that the offsets in the file and in memory have to be congruent modulo N to each other, not that all the addresses have to be a multiple of N. Paul. |
|
From: Tom H. <th...@cy...> - 2004-11-30 18:30:06
|
In message <1101839086.4125.7.camel@localhost>
Jeremy Fitzhardinge <je...@go...> wrote:
> On Tue, 2004-11-30 at 08:58 +0000, Tom Hughes wrote:
> > > An alternative way to write this patch is to just set 'align' to
> > > VKI_PAGE_SIZE.
> >
> > Doesn't that mean we're ignoring the alignment in the ELF header?
>
> Yes. The original ume code assumed the ELF alignment was page size, but
> it seems that x86_64 uses a 1Mbyte alignment, even though its page size
> is 4k. Did you check in a fix for that, or just propose a fix?
It wasn't checked in, but Nick had it in his x86-64 build.
The problem is/was that although the ELF file has a 1Mb alignment
specified the kernel still only maps the pages that are needed - it
doesn't round the mapping to a 1Mb alignment as I recall.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|