Date: Sun, 21 Sep 2008 15:26:52 +0200 (CEST) From: Juergen Lock <nox@jelal.kn-bremen.de> To: jhb@freebsd.org Cc: freebsd-hackers@freebsd.org, Navdeep Parhar <nparhar@gmail.com> Subject: Re: kgdb's add-kld broken on amd64 Message-ID: <200809211326.m8LDQq16065877@saturn.kn-bremen.de> In-Reply-To: <200809171628.52406.jhb@freebsd.org> 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
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 <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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200809211326.m8LDQq16065877>