Re: amd64 kernel modules: mapping sections to addresses
on 22/06/2010 01:00 Navdeep Parhar said the following: > > I'm not so sure about this. There is code inside the second switch that runs > whether sh_size is 0 or not. Either all of it is pointless code (when sh_size > is 0) or or you'll make sure that it still runs, right? It's definitely pointless. [IMHO :-)] -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: amd64 kernel modules: mapping sections to addresses
On Tue, Jun 22, 2010 at 12:34:49AM +0300, Andriy Gapon wrote: > on 21/06/2010 23:44 Navdeep Parhar said the following: > > On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote: > >> On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: > >>> on 21/06/2010 18:43 John Baldwin said the following: > np@ has a patch to gdb to fix this for kgdb. I haven't committed it as > it > patched gdb internals and wasn't in a kgdb-specific place, but I'm not > >> sure of > a better way to fix kgdb. > >>> Oh, yes, section mapping is done in common gdb code. > >>> Perhaps kld.c shouldn't call build_section_table, but directly call > >>> bfd_map_over_sections with a custom variant of add_to_section_table? > >>> Can you please share the patch? > >> It was deeper level than that, I'd have to dig it up. > > > > I'm using this patch these days: > > http://people.freebsd.org/~np/kgdb+kld+amd64.diff > > > > The changes to the kernel linker were not required originally. See this > > for why they had to be made: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html > > > > The patch is quite crude and I have no idea how it behaves on other > > platforms. > > Thanks a lot! These are exact issues that I hit and the patches are what I > think they should be, take or give. I don't think they are really crude. > I will try to get them committed. > > Kernel linker change is good as is, I'd just like to move the zero size check > before the switch statement. I'm not so sure about this. There is code inside the second switch that runs whether sh_size is 0 or not. Either all of it is pointless code (when sh_size is 0) or or you'll make sure that it still runs, right? Regards, Navdeep > > gdb change - I'd rather do it via kld_current_sos, > kld_relocate_section_addresses. I'd like to avoid changing common gdb code > for > a variety of reasons. > > -- > Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: amd64 kernel modules: mapping sections to addresses
on 21/06/2010 23:44 Navdeep Parhar said the following: > On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote: >> On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: >>> on 21/06/2010 18:43 John Baldwin said the following: np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it patched gdb internals and wasn't in a kgdb-specific place, but I'm not >> sure of a better way to fix kgdb. >>> Oh, yes, section mapping is done in common gdb code. >>> Perhaps kld.c shouldn't call build_section_table, but directly call >>> bfd_map_over_sections with a custom variant of add_to_section_table? >>> Can you please share the patch? >> It was deeper level than that, I'd have to dig it up. > > I'm using this patch these days: > http://people.freebsd.org/~np/kgdb+kld+amd64.diff > > The changes to the kernel linker were not required originally. See this > for why they had to be made: > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html > > The patch is quite crude and I have no idea how it behaves on other > platforms. Thanks a lot! These are exact issues that I hit and the patches are what I think they should be, take or give. I don't think they are really crude. I will try to get them committed. Kernel linker change is good as is, I'd just like to move the zero size check before the switch statement. gdb change - I'd rather do it via kld_current_sos, kld_relocate_section_addresses. I'd like to avoid changing common gdb code for a variety of reasons. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [patch] extending alloc_unr(9) to allocate specific unit numbers
On Mon, Jun 21, 2010 at 07:25:10PM +, Poul-Henning Kamp wrote: > In message <201006211109.11653@freebsd.org>, John Baldwin writes: > >On Saturday 19 June 2010 11:48:22 am Jaakko Heinonen wrote: > > >> As an example here is md(4) converted to use > >> alloc_unr() / alloc_unr_specific(): > >> > >>http://people.freebsd.org/~jh/patches/md-alloc_unr.diff > > > >This sounds useful to me. Perhaps ask p...@? > > My only worry is that if people start to use this indiscriminantly to > store random collections of numbers, then it is far from the optimal > data structure for it. > > Other than that: go for it. IIRC this is the one missing feature we need to convert if_clone to unr so I support it. -- Brooks pgpv2dZapZkSo.pgp Description: PGP signature
Re: amd64 kernel modules: mapping sections to addresses
On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote: > On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: > > on 21/06/2010 18:43 John Baldwin said the following: > > > np@ has a patch to gdb to fix this for kgdb. I haven't committed it as > > > it > > > patched gdb internals and wasn't in a kgdb-specific place, but I'm not > sure of > > > a better way to fix kgdb. > > > > Oh, yes, section mapping is done in common gdb code. > > Perhaps kld.c shouldn't call build_section_table, but directly call > > bfd_map_over_sections with a custom variant of add_to_section_table? > > Can you please share the patch? > > It was deeper level than that, I'd have to dig it up. I'm using this patch these days: http://people.freebsd.org/~np/kgdb+kld+amd64.diff The changes to the kernel linker were not required originally. See this for why they had to be made: http://lists.freebsd.org/pipermail/freebsd-hackers/2009-November/030093.html The patch is quite crude and I have no idea how it behaves on other platforms. Regards, Navdeep > > > Still, what about a small tool, elf(3)-base porgram or objdump+objcopy shell > > script, that would set section addresses in amd64 .ko (relocatable object > file) > > similarly to how they are set in i386 .ko (full-blown DSO)? > > Or is this too much useless hassle? > > No idea. If this worked and just let gdb work automatically that would be a > nice fix to just put into the build process. > > -- > John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: amd64 kernel modules: mapping sections to addresses
On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote: > on 21/06/2010 18:43 John Baldwin said the following: > > np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it > > patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of > > a better way to fix kgdb. > > Oh, yes, section mapping is done in common gdb code. > Perhaps kld.c shouldn't call build_section_table, but directly call > bfd_map_over_sections with a custom variant of add_to_section_table? > Can you please share the patch? It was deeper level than that, I'd have to dig it up. > Still, what about a small tool, elf(3)-base porgram or objdump+objcopy shell > script, that would set section addresses in amd64 .ko (relocatable object file) > similarly to how they are set in i386 .ko (full-blown DSO)? > Or is this too much useless hassle? No idea. If this worked and just let gdb work automatically that would be a nice fix to just put into the build process. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [patch] extending alloc_unr(9) to allocate specific unit numbers
In message <201006211109.11653@freebsd.org>, John Baldwin writes: >On Saturday 19 June 2010 11:48:22 am Jaakko Heinonen wrote: >> As an example here is md(4) converted to use >> alloc_unr() / alloc_unr_specific(): >> >> http://people.freebsd.org/~jh/patches/md-alloc_unr.diff > >This sounds useful to me. Perhaps ask p...@? My only worry is that if people start to use this indiscriminantly to store random collections of numbers, then it is far from the optimal data structure for it. Other than that: go for it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
About Marvell Yukon drivers skgeinit and sky2
Hi, As I understand, there are 2 flavors of the Marvel Yukon driver. One is for Yukon-I devices, and is called skgeinit, and other is for Yukon-II devices and called sky2 driver. Looking at the release notes for 7.0, it looks like this driver which was in sys/dev/yukon, is now present as the msk(4) driver in sys/dev/msk and sys/dev/sk?. I do not see a yukon under dev anymore. I see only 2 files in the msk directory, is it really moved here? Is the Yukon-II sky2 driver support present in Freebsd 6.1? How easy would it to backport this to 6.1? If yes, then is there a way to disable the skgeinit(which seems to be the default) and enable the sky2 driver? Anjali ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: amd64 kernel modules: mapping sections to addresses
on 21/06/2010 18:43 John Baldwin said the following: > np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it > patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure > of > a better way to fix kgdb. Oh, yes, section mapping is done in common gdb code. Perhaps kld.c shouldn't call build_section_table, but directly call bfd_map_over_sections with a custom variant of add_to_section_table? Can you please share the patch? Still, what about a small tool, elf(3)-base porgram or objdump+objcopy shell script, that would set section addresses in amd64 .ko (relocatable object file) similarly to how they are set in i386 .ko (full-blown DSO)? Or is this too much useless hassle? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: amd64 kernel modules: mapping sections to addresses
On Monday 21 June 2010 10:39:08 am Andriy Gapon wrote: > > I've noticed that on amd64 addresses (sh_addr) of all sections in a kernel module > are zeros. > This is unlike kernel itself and i386 modules. > > Kernel linker maps SHT_PROGBITS and SHT_NOBITS sections sequentially starting at a > certain base address and taking into account their sizes and alignment requirements. > > On the other hand, kgdb calculates section address as module base address plus > sh_addr of the section. Which puts all sections, e.g. .text, .data, .bss, at the > same address. This is correct only for .text which is normally the first section > described in a header. > > DTrace situation is even worse, because don't even take into account module base > address, not speaking of section relative addresses. > > Perhaps we should put some sh_addr values into amd64 kernel modules that would > match calculations done in link_elf_load_file. > Or should we replicate logic from link_elf_load_file in all places that need to > map loaded module's sections to load addresses? > > What do you think? > Thanks! > > P.S. > As I understand CTF data includes a symbol table. > What kind of symbol addresses is used there? Are they relative within a > corresponding section? Or something else? np@ has a patch to gdb to fix this for kgdb. I haven't committed it as it patched gdb internals and wasn't in a kgdb-specific place, but I'm not sure of a better way to fix kgdb. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [patch] extending alloc_unr(9) to allocate specific unit numbers
On Saturday 19 June 2010 11:48:22 am Jaakko Heinonen wrote: > > Hi, > > I wrote a patch to extend the kernel unit number allocator for > allocating specific unit numbers. The patch adds a new function > alloc_unr_specific() which returns the requested unit number if it is > free and -1 if the number is already allocated or out of the range. > Unlike alloc_unr(), alloc_unr_specific() may allocate memory and thus > sleep. > > The patch is here: > > http://people.freebsd.org/~jh/patches/alloc_unr_specific.diff > > I think that this functionality has been requested by some people. > Reviews/comments? > > As an example here is md(4) converted to use > alloc_unr() / alloc_unr_specific(): > > http://people.freebsd.org/~jh/patches/md-alloc_unr.diff This sounds useful to me. Perhaps ask p...@? -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
amd64 kernel modules: mapping sections to addresses
I've noticed that on amd64 addresses (sh_addr) of all sections in a kernel module are zeros. This is unlike kernel itself and i386 modules. Kernel linker maps SHT_PROGBITS and SHT_NOBITS sections sequentially starting at a certain base address and taking into account their sizes and alignment requirements. On the other hand, kgdb calculates section address as module base address plus sh_addr of the section. Which puts all sections, e.g. .text, .data, .bss, at the same address. This is correct only for .text which is normally the first section described in a header. DTrace situation is even worse, because don't even take into account module base address, not speaking of section relative addresses. Perhaps we should put some sh_addr values into amd64 kernel modules that would match calculations done in link_elf_load_file. Or should we replicate logic from link_elf_load_file in all places that need to map loaded module's sections to load addresses? What do you think? Thanks! P.S. As I understand CTF data includes a symbol table. What kind of symbol addresses is used there? Are they relative within a corresponding section? Or something else? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: "Checksum mismatch -- will transfer entire file"
Gary Jennejohn wrote: > > > > > > > csup already has a CVS mode, at least in 9-current. I don't use older > > > > versions of FreeBSD so I don't know whether it supports CVS there. > > > > > > It does at least down to 7.x. > > > > High time to fix this botheration, isn't it? > > > > This has been discussed in some mailing list (don't remember which) before. > > IIRC the problem is caused by the mechanism used to check commits from svn > into CVS. simon@ holds a different view: http://lists.freebsd.org/pipermail/freebsd-hubs/2009-August/002083.html > I doubt it's easy to fix and IMO not worth the bother. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Are POSIX mqueues supposed to be functional on FreeBSD?
On Mon, Jun 21, 2010 at 11:41:58AM +1200, Andrew Thompson wrote: > On 21 June 2010 10:11, Garrett Cooper wrote: > > On Sun, Jun 20, 2010 at 3:06 PM, Stathis Kamperis > > wrote: > >> 2010/6/21 Garrett Cooper : > >>> Err... I ran an mqueue test and it popped up with ENOSYS. Which > >>> makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I > >>> looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I > >> > >> Hi, > >> > >> did you first load the respective kernel module (mqueuefs or something > >> like that) ? > > > > Duh... should have checked that first I suppose: no, it isn't loaded. > > However, it doesn't appear to compile with my copy of src: > > > > # make -C /sys/modules/mqueue/ all install > > Warning: Object directory not changed from original > > /usr/src/sys/modules/mqueue > > cc -O2 -pipe -fno-strict-aliasing -pipe -O2 -march=nocona -Werror > > -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq > > -finline-limit=8000 --param inline-unit-growth=100 --param > > large-function-growth=1000 -fno-common -fno-omit-frame-pointer > > -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 > > -mno-sse3 -mno-mmx -mno-3dnow -msoft-float > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > > -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls > > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign > > -fformat-extensions -c > > /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c > > /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c:48:24: error: > > opt_compat.h: No such file or directory > > *** Error code 1 > > > > Stop in /usr/src/sys/modules/mqueue. > > # find /usr/src/ -name opt_compat.h > > > > So I'll need to hunt down what's going on with the missing header. > > opt_* headers are auto-generated by the kernel config. Just add > opt_compat.h to sys/modules/mqueue/Makefile right after opt_posix.h Apparently, missed opt_compat.h in module Makefile is my fault. Would you, please, commit the fix ? pgpuvjypPAzsu.pgp Description: PGP signature
Re: "Checksum mismatch -- will transfer entire file"
On Mon, 21 Jun 2010 08:45:17 +0700 Victor Sudakov wrote: > Christian Weisgerber wrote: > > > > > csup already has a CVS mode, at least in 9-current. I don't use older > > > versions of FreeBSD so I don't know whether it supports CVS there. > > > > It does at least down to 7.x. > > High time to fix this botheration, isn't it? > This has been discussed in some mailing list (don't remember which) before. IIRC the problem is caused by the mechanism used to check commits from svn into CVS. I doubt it's easy to fix and IMO not worth the bother. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
