[Bug ld/12376] File offsets for PT_LOAD segments and resulting inequivalent memory aliases
http://sourceware.org/bugzilla/show_bug.cgi?id=12376
--- Comment #7 from dave at hiauly1 dot hia.nrc.ca dave at hiauly1 dot
hia.nrc.ca 2011-02-14 14:51:27 UTC ---
If they are the same page, doesn't that mean your maxpagesize is wildly
incorrect? You must have maxpagesize at least as large as a memory page.
maxpagesize is set to 0x1000 which is the standard page size for parisc
linux.
The issue is not the virtual addresses of the page but the placement
of the loadable segments in the file. These segments are mmap'd from
the file to physical memory. Although the pages could be different
in memory, they are not.
The issue can be seen by looking at the mappings for a trivial program like:
int main () { return 0 }
For the the main executable, there is only one file page for text
and data. Run program under gdb with a break on main. Then inspect
the mappings.
The two mappings could be made equivalent, but this messes up shared
library support.
The hardware can support larger page sizes, but as far as I know nobody
uses them on linux. There was some effort to provide support for larger
page sizes in the linux kernel but I don't believe the cache flush and
TLB support is complete.
Possibly, ELF_COMMONPAGESIZE should be defined and ELF_MAXPAGESIZE
increased to the linux kernel maximum.
Dave
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12376] File offsets for PT_LOAD segments and resulting inequivalent memory aliases
http://sourceware.org/bugzilla/show_bug.cgi?id=12376
--- Comment #9 from dave at hiauly1 dot hia.nrc.ca dave at hiauly1 dot
hia.nrc.ca 2011-02-14 17:26:00 UTC ---
On Mon, 14 Feb 2011, ian at airs dot com wrote:
If that is indeed a limitation of PA Linux, then the only fix is to change the
default linker script so that the first page of the data segment does not
overlap with the last page of the text segment. The way to do that is to set
DATA_ADDR in the appropriate ld/emulparams file. For example,
DATA_ADDR=ALIGN(${MAXPAGESIZE})
That should always force the data segment to start on a new page.
I'll take another look but I think this only changes the virtual address
of the data segment and not the underlying file organization.
Looking at a typical file compiled for hppa64-hpux with readelf, we have:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSizMemSiz Flags Align
LOAD 0x 0x4000 0x
0x00024bc8 0x00024bc8 R E8
LOAD 0x00025000 0x8001 0x
0x2ef0 0x3550 RW 8
Note the file offset for the data segment starts on a page boundary.
I think that I need to achieve the same on hppa-linux.
Dave
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12376] File offsets for PT_LOAD segments and resulting inequivalent memory aliases
http://sourceware.org/bugzilla/show_bug.cgi?id=12376 --- Comment #11 from dave at hiauly1 dot hia.nrc.ca dave at hiauly1 dot hia.nrc.ca 2011-02-14 23:22:20 UTC --- On Mon, 14 Feb 2011, ian at airs dot com wrote: If you arrange for the data section to start on a new page, then the linker will always put that data section on a new page in the file. It has to, because ELF specifies that the file offset is always equal to the page offset modulo the page size (unless you link with -N or -n). Ah, that's the clue! Testing fix. Dave -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12376] File offsets for PT_LOAD segments and resulting inequivalent memory aliases
http://sourceware.org/bugzilla/show_bug.cgi?id=12376 --- Comment #5 from dave at hiauly1 dot hia.nrc.ca dave at hiauly1 dot hia.nrc.ca 2011-02-14 03:40:21 UTC --- On Mon, 14 Feb 2011, amodra at gmail dot com wrote: These in fact point to the same page in physical memory. Really? 0001-00011000 and 00011000-00012000 are not different pages? They map to the same page as far as I can tell (both maps appear in the list iterated using vma_prio_tree_foreach(mpnt, iter, mapping-i_mmap, pgoff, pgoff)). This can also be seen by looking at /proc/$PID/maps. When multiple shared writeable mappings exist, I believed they are COWed. So, effectively only one map is writeable. Non equivalent aliases are a problem for architectures such as PA8800/PA8900. They don't support non equivalent aliases in the sense that a write doesn't invalidate non equivalent aliases. The only thing that saves us is the former address range is write protected, and it's rare to try to read using the text map. It seems possible that the text map could be corrupted via the data map. So, this might be a security issue. The V-Class machines are even worse than PA8800/PA8900 because they don't support non equivalent aliases regardless of whether they are read-only or not. These non equivalent aliases occur typically on the boundary page between text and data. The linux dynamic loader mmaps these regions as MAP_FIXED. They are not mapped with MAP_SHARED but it seems the maps are shared for shared libraries. So far, it seems the hppa linux dynamic loader always maps shared pages with equivalent aliases except for the boundary page. I think this is potentially an issue for certain MIPS and ARM cpus but I don't know the details on whether they support non equivalent aliases or not. As far as I can tell, the same occurs for x86, etc, but I don't think the non equivalent aliases matter, at least on linux. On the other hand, it looks like windows starts sections on page boundaries. Probably, it would be best if load segments were aranged in executables to optionally start on a file page boundary. This would avoid the double flush and having two non equivalent address ranges map to the same page. Don't really want to start all sections on a page boundary as this would waste a lot of file space. I have looked a bit at trying to do this, but don't have a solution at the moment. Dave -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12402] ld --disable-plugins configure options doesn't work
http://sourceware.org/bugzilla/show_bug.cgi?id=12402 --- Comment #4 from dave at hiauly1 dot hia.nrc.ca dave at hiauly1 dot hia.nrc.ca 2011-02-01 15:07:35 UTC --- Is there else anything apart from GCC PR47274, which I'm looking at? There's about three hundred GCC lto/plugin fails. There's a couple of PRs. Can you quote the PR numbers please? I couldn't figure out which ones you meant from a quick bit of searching. The other one is GCC PR47827. Dave -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12402] ld --disable-plugins configure options doesn't work
http://sourceware.org/bugzilla/show_bug.cgi?id=12402 --- Comment #2 from dave at hiauly1 dot hia.nrc.ca dave at hiauly1 dot hia.nrc.ca 2011-02-01 04:30:04 UTC --- GCC lto/plugin support is currently broken on this target. Is there else anything apart from GCC PR47274, which I'm looking at? There's about three hundred GCC lto/plugin fails. There's a couple of PRs. It's hard to tell whether they are all the same bug or not. Dave -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12358] FAIL: ld-elf/textaddr2
http://sourceware.org/bugzilla/show_bug.cgi?id=12358 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca dave at hiauly1 dot hia.nrc.ca 2010-12-31 20:49:44 UTC --- Attached dump.out. Regexp appears to fail because of differences in FileSiz, MemSiz and Flg. Dave -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12359] FAIL: ld-elf/textaddr6
http://sourceware.org/bugzilla/show_bug.cgi?id=12359 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca dave at hiauly1 dot hia.nrc.ca 2010-12-31 21:14:45 UTC --- Attached dump.out. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
