From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 21 13:55:08 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3B251065676; Sun, 21 Sep 2008 13:55:08 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.freebsd.org (Postfix) with ESMTP id 496FB8FC1B; Sun, 21 Sep 2008 13:55:08 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: by gwyn.kn-bremen.de (Postfix, from userid 10) id E919B191A4A; Sun, 21 Sep 2008 15:28:00 +0200 (CEST) Received: from saturn.kn-bremen.de (noident@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.14.2/8.13.8) with ESMTP id m8LDQrVB065878; Sun, 21 Sep 2008 15:26:53 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.14.2/8.13.6/Submit) id m8LDQq16065877; Sun, 21 Sep 2008 15:26:52 +0200 (CEST) (envelope-from nox) Date: Sun, 21 Sep 2008 15:26:52 +0200 (CEST) From: Juergen Lock Message-Id: <200809211326.m8LDQq16065877@saturn.kn-bremen.de> To: jhb@freebsd.org X-Newsgroups: local.list.freebsd.hackers In-Reply-To: <200809171628.52406.jhb@freebsd.org> References: <200809171131.30819.jhb@freebsd.org> Organization: home X-Mailman-Approved-At: Sun, 21 Sep 2008 13:59:41 +0000 Cc: freebsd-hackers@freebsd.org, Navdeep Parhar Subject: Re: kgdb's add-kld broken on amd64 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2008 13:55:08 -0000 In article <200809171628.52406.jhb@freebsd.org> you write: >On Wednesday 17 September 2008 03:51:02 pm Navdeep Parhar wrote: >> Hello John, >> >> The patch did NOT fix the problem. Read on for more.... >> >> On Wed, Sep 17, 2008 at 8:31 AM, John Baldwin wrote: >> > On Tuesday 16 September 2008 04:07:46 pm Navdeep Parhar wrote: >> >> Hello everyone, >> >> >> >> The add-kld command in kgdb does not work as expected on amd64 >> >> (I'm using a recent HEAD, problem may affect others too). It uses >> >> the same address for all sections: >> >> >> >> (kgdb) add-kld if_cxgb.ko >> >> add symbol table from file "/boot/kernel/if_cxgb.ko" at >> >> .text_addr = 0xffffffff81022000 >> >> .rodata_addr = 0xffffffff81022000 >> >> .rodata.str1.8_addr = 0xffffffff81022000 >> >> .rodata.str1.1_addr = 0xffffffff81022000 >> >> set_modmetadata_set_addr = 0xffffffff81022000 >> >> set_sysctl_set_addr = 0xffffffff81022000 >> >> set_sysinit_set_addr = 0xffffffff81022000 >> >> set_sysuninit_set_addr = 0xffffffff81022000 >> >> .data_addr = 0xffffffff81022000 >> >> .bss_addr = 0xffffffff81022000 >> >> (y or n) >> >> >> >> This is not correct. The .text section's address is OK but the >> >> others are not. >> >> >> >> The problem seems to be that all amd64 kernel objects have VMA set >> >> to 0 for all sections. add_section() in gnu/usr.bin/gdb/kgdb/kld.c >> >> uses this VMA to adjust the address of the section: >> >> >> >> address = asi->base_addr + bfd_get_section_vma(bfd, sect); >> >> >> >> objdump -h shows that the userland objects on amd64 and all >> >> objects (kernel + userland) on i386 set VMA. It is only the >> >> kernel objects on amd64 that have VMA = 0. (sample output from >> >> amd64 and i386 machines appended at the end) >> >> >> >> For the time being I've patched kgdb to consider the file offset >> >> and not the VMA while calculating the section address. It seems >> >> to work but is probably not the right way to fix the problem. >> >> >> >> Any thoughts? >> > >> > Hmm, I wonder if this is because on amd64 modules are .o's rather >than .so's. >> > It is. File offset isn't quite right. Instead, the way >> > sys/kern/link_elf_obj.c works is that it just loads the PROGBITS (text, >code, >> > etc.) and NOBITS (bss) sections in the order they are in the file and >> > concatenates them. So, the relocation logic in kgdb will need to be >updated >> > to recognize a .o vs .so and apply that algorithm for .o files. >> > >> > Actually, what I've done is to replace the home-rolled section relocation >> > stuff with the gdb primitives that the solib code in gdb uses. It works >here >> > on i386, and hopefully this will fix this as this is how the sharedlibrary >> > kld stuff is doing the relocations: >> >> I had to modify the patch a bit as add-kld -> build_section_table() -> >xfree() >> was a bad free and led to bus errors or segv: >> >> - struct section_table *sections, *sections_end, *s; >> + struct section_table *sections = NULL, *sections_end = NULL, *s; >> >> After fixing that, add-kld still wouldn't pick up the correct >> addresses: >> >> (kgdb) add-kld if_cxgb.ko >> add symbol table from file "/boot/kernel/if_cxgb.ko" at >> .text_addr = 0xffffffff81022000 >> .rodata_addr = 0xffffffff81022000 >> .rodata.str1.8_addr = 0xffffffff81022000 >> .rodata.str1.1_addr = 0xffffffff81022000 >> set_modmetadata_set_addr = 0xffffffff81022000 >> set_sysctl_set_addr = 0xffffffff81022000 >> set_sysinit_set_addr = 0xffffffff81022000 >> set_sysuninit_set_addr = 0xffffffff81022000 >> .data_addr = 0xffffffff81022000 >> .bss_addr = 0xffffffff81022000 >> >> With the patch the section relocation is still taking place based >> on the VMA (which is 0 for amd64 modules as I pointed out >> earlier). So the behaviour is no different than before. If I >> read the code right, each section's addr is calculated as: >> >> load_kld -> build_section_table -> add_to_section_table >> >> This sets it to bfd_section_vma(abfd, asect), which is no good >> for amd64 kernel modules. > >Well, this means gdb can't handle loading .o's, though I guess that is to be >expected. :( Even if I fix add-kld there's probably no way I can easily fix >the sharedlibrary stuff w/o ripping gdb itself up a bunch. I haven't looked at what the gdb patch exactly does, but I was able to load klds the old way on amd64 using a patched asf(8) as posted here: http://lists.freebsd.org/pipermail/freebsd-amd64/2008-May/011062.html Better than nothing I guess... :) Juergen