From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 17 21:18:34 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 45DAA106564A for ; Wed, 17 Sep 2008 21:18:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id D221A8FC1A for ; Wed, 17 Sep 2008 21:18:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m8HLIL9v009566; Wed, 17 Sep 2008 17:18:27 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Navdeep Parhar" Date: Wed, 17 Sep 2008 16:28:52 -0400 User-Agent: KMail/1.9.7 References: <200809171131.30819.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809171628.52406.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 17 Sep 2008 17:18:28 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/8271/Wed Sep 17 12:58:50 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org 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: Wed, 17 Sep 2008 21:18:34 -0000 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. -- John Baldwin