Date: Wed, 17 Sep 2008 16:28:52 -0400 From: John Baldwin <jhb@freebsd.org> To: "Navdeep Parhar" <nparhar@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: kgdb's add-kld broken on amd64 Message-ID: <200809171628.52406.jhb@freebsd.org> In-Reply-To: <d04e16b70809171251h474df74h89829048582f994a@mail.gmail.com> References: <d04e16b70809161307p11a44c53i4e0a33edc12257c8@mail.gmail.com> <200809171131.30819.jhb@freebsd.org> <d04e16b70809171251h474df74h89829048582f994a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200809171628.52406.jhb>