Изучение mmaped адресов с использованием GDB - PullRequest
Новая
       24

Изучение mmaped адресов с использованием GDB

15 голосов
/ 17 марта 2009

Я использую драйвер, который я разместил на Прямой доступ к памяти в Linux , чтобы преобразовать некоторый физический ОЗУ в адрес пользовательского пространства. Однако я не могу использовать GDB для просмотра любого адреса; то есть x 0x12345678 (где 0x12345678 - возвращаемое значение mmap) завершается с ошибкой «Не удается получить доступ к памяти по адресу 0x12345678».

Есть ли способ сообщить GDB, что эту память можно просматривать? В качестве альтернативы, есть ли что-то другое, что я могу сделать в mmap (вызов или реализация там foo_mmap), что позволит ему получить доступ к этой памяти?

Обратите внимание, что я спрашиваю не о / dev / mem (как в первом там фрагменте), а о mmap в память, полученную с помощью ioremap (), virt_to_phys () и remap_pfn_range ()

Ответы [ 7 ]

12 голосов
/ 23 марта 2009

Я считаю, что Linux не делает доступной память ввода / вывода через ptrace (). Вы могли бы написать функцию, которая просто читает адрес mmap и вызывает его вызов GDB. Вот немного измененная версия вашей программы foo-user.c вместе с выводом из сеанса GDB. 

#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/mman.h>

char *mptr;

char peek(int offset)
{
    return mptr[offset];
}

int main(void)
{
    int fd;
    fd = open("/dev/foo", O_RDWR | O_SYNC);
    if (fd == -1) {
        printf("open error...\n");
        return 1;
    }
    mptr = mmap(0, 1 * 1024 * 1024, PROT_READ | PROT_WRITE,
             MAP_FILE | MAP_SHARED, fd, 4096);
    printf("On start, mptr points to 0x%lX.\n", (unsigned long) mptr);
    printf("mptr points to 0x%lX. *mptr = 0x%X\n", (unsigned long) mptr,
           *mptr);
    mptr[0] = 'a';
    mptr[1] = 'b';
    printf("mptr points to 0x%lX. *mptr = 0x%X\n", (unsigned long) mptr,
           *mptr);
    close(fd);
    return 0;
}



$ make foo-user CFLAGS=-g
$ gdb -q foo-user
(gdb) break 27
Breakpoint 1 at 0x804855f: file foo-user.c, line 27.
(gdb) run
Starting program: /home/me/foo/foo-user 
On start, mptr points to 0xB7E1E000.
mptr points to 0xB7E1E000. *mptr = 0x61

Breakpoint 1, main () at foo-user.c:27
27          mptr[0] = 'a';
(gdb) n
28          mptr[1] = 'b';
(gdb) print peek(0)
$1 = 97 'a'
(gdb) print peek(1)
$2 = 98 'b'
10 голосов
/ 26 сентября 2011

У меня есть ответ на вашу загадку :) Я искал повсюду в Интернете без особой помощи и, наконец, сам отладил.

Этот пост был хорошей отправной точкой для меня. Я хотел добиться чего-то похожего, я реализовал драйвер char с MMAP, чтобы сопоставить мою пользовательскую управляемую память с процессом пользовательского пространства. При использовании GDB ptrace PEEK вызывает access_process_vm () для доступа к любой памяти в вашем VMA. Это вызывает ошибку EIO, поскольку общий доступ не может получить PA вашей памяти. Оказывается, вы должны реализовать функцию доступа к этой памяти, реализуя .access вашей VMA vm_operations_struct. Ниже приведен пример: 

//Below code needs to be implemented by your driver:
static struct vm_operations_struct custom_vm_ops = {
    .access = custom_vma_access,
};

static inline int custom_vma_access(struct vm_area_struct *vma, unsigned long addr,
          void *buf, int len, int write)
{
    return custom_generic_access_phys(vma, addr, buf, len, write);
}

static int custom_generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
            void *buf, int len, int write)
{
    void __iomem *maddr;
    //int offset = (addr & (PAGE_SIZE-1)) - vma->vm_start;
    int offset = (addr) - vma->vm_start;

    maddr = phys_to_virt(__pa(custom_mem_VA));
    if (write)
        memcpy_toio(maddr + offset, buf, len);
    else
        memcpy_fromio(buf, maddr + offset, len);

    return len;
}
2 голосов
/ 22 марта 2009

Насколько я понимаю, GDB будет использовать ptrace , чтобы копаться в памяти вашего процесса. Возможно, вам следует написать простую программу, которая просто присоединяется к вашему процессу и использует ptrace для чтения из этой памяти. Это может помочь сузить суть проблемы. Если с этим нет проблем, то вы знаете, что я ошибаюсь :), или с GDB происходит что-то подозрительное.

1 голос
/ 01 июня 2016

Чтобы получить доступ к mmapped памяти, GDB вызовет ptrace, который затем вызовет __access_remote_vm () для доступа к mmapped памяти. Если память отображается с флагами, такими как VMIO | VM_PFNMAP (например, remap_pfn_range () устанавливает их), GDB будет обращаться к памяти, хотя метод доступа vm определен пользователями.

Вместо написания нашей собственной реализации для access (), ядро ​​уже предоставляет универсальную версию, называемую generic_access_phys (), и этот метод можно легко связать с помощью vm_operations_struct, как это делало устройство / dev / mem: 

static const struct vm_operations_struct mmap_mem_ops = {
        .access = generic_access_phys };

int mmap_mem()
{
    .... ....
    vma->vm_ops = &mmap_mem_ops;
    .... ....
}
1 голос
/ 14 июля 2009

вы идете "информационные файлы" 

(gdb) help info files
Names of targets and files being debugged.
Shows the entire stack of targets currently in use (including the exec-file,
core-file, and process, if any), as well as the symbol file name.
(gdb) info files
Symbols from "/bin/ls".
Unix child process:
        Using the running image of child Thread 4160418656 (LWP 10729).
        While running this, GDB does not access memory from...
Local exec file:
        `/bin/ls', file type elf32-powerpc.
        Entry point: 0x10002a10
        0x10000134 - 0x10000141 is .interp
        0x10000144 - 0x10000164 is .note.ABI-tag
        0x10000164 - 0x100008f8 is .gnu.hash
        0x100008f8 - 0x10001728 is .dynsym
        0x10001728 - 0x100021f3 is .dynstr
        0x100021f4 - 0x100023ba is .gnu.version
...
        0x0ffa8300 - 0x0ffad8c0 is .text in /lib/libacl.so.1
        0x0ffad8c0 - 0x0ffad8f8 is .fini in /lib/libacl.so.1
        0x0ffad8f8 - 0x0ffadbac is .rodata in /lib/libacl.so.1
        0x0ffadbac - 0x0ffadd58 is .eh_frame_hdr in /lib/libacl.so.1
        0x0ffadd58 - 0x0ffae4d8 is .eh_frame in /lib/libacl.so.1
        0x0ffbe4d8 - 0x0ffbe4e0 is .ctors in /lib/libacl.so.1
        0x0ffbe4e0 - 0x0ffbe4e8 is .dtors in /lib/libacl.so.1
...

(gdb) info sh
From        To          Syms Read   Shared Object Library
0xf7fcf960  0xf7fe81a0  Yes         /lib/ld.so.1
0x0ffd0820  0x0ffd5d10  Yes         /lib/librt.so.1
0x0ffa8300  0x0ffad8c0  Yes         /lib/libacl.so.1
0x0ff6a840  0x0ff7f4f0  Yes         /lib/libselinux.so.1
0x0fdfe920  0x0ff1ae70  Yes         /lib/libc.so.6
0x0fda23d0  0x0fdb0db0  Yes         /lib/libpthread.so.0

В противном случае вы можете использовать «mem» для настройки диапазонов памяти. 

(gdb) mem 1 1414
(gdb) info mem
Num Enb Low Addr   High Addr  Attrs
1   y   0x00000001 0x00000586 rw nocache
(gdb) disable mem 1
(gdb) info mem
Num Enb Low Addr   High Addr  Attrs
1   n   0x00000001 0x00000586 rw nocache
0 голосов
/ 07 мая 2010

Если вы откроете сокет AF_PACKET и отобразите его, GDB не сможет получить доступ к этой памяти. Так что нет проблем с вашим водителем. Это либо проблема с ptrace, либо с gdb.

0 голосов
/ 21 марта 2009

Я думаю, что если эта память недоступна GDB, то она не отображается в адресное пространство вашего процесса, и вы получаете «Невозможно получить доступ к памяти по адресам 0x12345678». Если бы это приложение работало нормально, вы бы получили ошибку сегментации. Также, возможно, ваш драйвер испорчен, и вы должны проверить, что вы действительно можете получить доступ к памяти изнутри ядра. Попробуйте с примером здесь: 

#include <cstdio>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>

int main() {
    int fd = open("/dev/zero", O_RDONLY);
    void* addr = mmap(NULL, 1024, PROT_READ, MAP_PRIVATE, fd, 0);
    for (int x = 0; x < 10; x++) {
        printf("%X\n", ((char*)addr)[x]);
    }
    close(fd);
    return 0;
}
...