Dirk Engling | 28 Jan 11:57 2015

libbconv

When upgrading my iconv I learnt that ports were suddenly missing
libiconv.so.2, and when I took a look, I actually did not find it but a
libbicon (notice the extra 'b').

ls /usr/local/lib/*iconv*
-r--r--r--  1 root  wheel    61510 27 Dez 14:07 libbiconv.a
lrwxr-xr-x  1 root  wheel       14 27 Dez 14:07 libbiconv.so ->
libbiconv.so.2
-r--r--r--  1 root  wheel    26136 27 Dez 14:07 libbiconv.so.2
-r--r--r--  1 root  wheel    64970 27 Dez 14:07 libbiconv_p.a
-rw-r--r--  1 root  wheel  1116336  7 Mai  2014 libiconv.a
-r--r--r--  1 root  wheel      916  7 Mai  2014 libiconv.la
lrwxr-xr-x  1 root  wheel       13  7 Mai  2014 libiconv.so -> libiconv.so.3
-r--r--r--  1 root  wheel  1088983  7 Mai  2014 libiconv.so.3

Is this intended?

  erdgeist
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Alexey Dokuchaev | 27 Jan 09:58 2015
Picon

Bug in ln(1), its manpage, or just misunderstanding?

Hi there,

Per man ln(1), it has -F option which:

    -F    If the target file already exists and is a directory, then remove
          it so that the link may occur.  The -F option should be used with
          either -f or -i options.  If none is specified, -f is implied.  The
          -F option is a no-op unless -s option is specified.

As I read it correctly, it basically removes empty directory so I can place
a link of the same name there:

    $ mkdir foo
    $ ln -sF /etc foo		# result should be: foo -> /etc

However, in ln.c, static int linkit(const char *source, const char *target,
int isdir) contains:

    /*
     * If the target is a directory (and not a symlink if hflag),
     * append the source's name.
     */
    if (isdir ||
        (lstat(target, &sb) == 0 && S_ISDIR(sb.st_mode)) ||
        (!hflag && stat(target, &sb) == 0 && S_ISDIR(sb.st_mode))) {
            if (strlcpy(bbuf, source, sizeof(bbuf)) >= sizeof(bbuf) ||
                (p = basename(bbuf)) == NULL ||
                snprintf(path, sizeof(path), "%s/%s", target, p) >=
                ...

(Continue reading)

Alfred Perlstein | 26 Jan 18:38 2015
Picon

libxo: bringing it in for netstat

Folks,

I have a huge number of commitments at work which will keep me from having the time to finish up my libxo
netstat work.  Or in fact most anything FreeBSD for the upcoming few weeks or months even.

I actually believe that the netstat port to libxo is ready for inclusion (almost) but in case there are bugs I
would likely not be responsive enough to keep a angry mob from forming.

I am wondering what I should do to make sure the code doesn't bit-rot and gets into the system ASAP? 

Is there anyone that can step forward to shepherd the code in?

Right now the work is here, but can be moved to an SVN project branch if needed:
  https://github.com/splbio/freebsd/tree/ap_libxo_master

This branch includes some things that can be backed out thanks to updates to libxo and other base things from
Phil and others.

Is anyone up for taking this over right now?

Again, If needed I can migrate it to an SVN project branch if a volunteer with sufficient skill steps up who
would prefer that during an upcoming weekend.

-Alfred
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

(Continue reading)

Yuri | 26 Jan 02:13 2015

'cacheflush' in FreeBSD ?

LLVM has the function llvm::sys::Memory::InvalidateInstructionCache, 
that invalidates instruction cache after they allocate memory for the 
binary code, and before they run it.
On Linux this function calls cachflush(2). And on FreeBSD this function 
is a noop (besides some related valgrind cache call).

FreeBSD doesn't have 'cacheflush' system call. So how is instruction 
cache flushed on FreeBSD? I suspect this is a bug in LLVM that this 
function is a noop.

libexec/rtld-elf also loads binary code in similar way, and it isn't 
clear from its source code how instruction cache flushing is handled there.

Can somebody clarify what is the equivalent of linux cachflush(2), and 
is this a bug that llvm::sys::Memory::InvalidateInstructionCache is a noop?

Yuri
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Yue Chen | 25 Jan 06:19 2015
Picon

How to get the source code of FreeBSD-Clang?

When I use the original versions (even 3.4.1) of LLVM/Clang to compile
FreeBSD kernel, it always has problems.

Since I need to modify something in LLVM source and then build the kernel,
where can I get the FreeBSD-friendly Clang/LLVM source code?

Thanks.
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Marcin Cieslak | 24 Jan 03:00 2015

Do I need <geom/geom.h> in <geom/gate/g_gate.h> ?

I am trying to write a GEOM gate module 
in C++ - for the project that is already
written 100% in C++ ....

Unfortunately, trying to #include <geom/gate/g_gate.h>
fails:

In file included from GEOMGate.cpp:1:
In file included from /usr/include/geom/gate/g_gate.h:37:
/usr/include/geom/geom.h:118:21: error: expected ';' after struct
        LIST_ENTRY(g_class)     class;
                           ^
/usr/include/geom/geom.h:118:22: error: declaration of anonymous class must be
      a definition
        LIST_ENTRY(g_class)     class;
                                ^
/usr/include/geom/geom.h:131:19: error: expected member name or ';' after
      declaration specifiers
        struct g_class          *class;
        ~~~~~~                   ^
/usr/include/geom/geom.h:186:10: error: expected member name or ';' after
      declaration specifiers
        void                    *private;
        ~~~~                     ^
/usr/include/geom/geom.h:215:10: error: expected member name or ';' after
      declaration specifiers
        void                    *private;
        ~~~~                     ^

I think C++ does not like using "class" in this context.
(Continue reading)

Wojciech Puchar | 23 Jan 22:24 2015
Picon

svn checkout head

tried both
svn checkout http://svn.freebsd.org/base/head /usr/src-current/

and svnlite

svn is from ports. no matter what i use - it ends with signal 11 after 
some files.

svn cleanup and svn update sometimes helps moving few files more

any ideas?
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Dmitry Luhtionov | 23 Jan 08:37 2015
Picon

Add AVIC bit to AMD SVM


--- src/sys/amd64/vmm/amd/svm.c.orig	2015-01-16 12:58:04.000000000 +0200
+++ src/sys/amd64/vmm/amd/svm.c	2015-01-23 09:29:10.000000000 +0200
 <at>  <at>  -80,6 +80,7  <at>  <at> 
 #define AMD_CPUID_SVM_DECODE_ASSIST	BIT(7)  /* Decode assist */
 #define AMD_CPUID_SVM_PAUSE_INC		BIT(10) /* Pause intercept filter. */
 #define AMD_CPUID_SVM_PAUSE_FTH		BIT(12) /* Pause filter threshold */
+#define AMD_CPUID_SVM_AVIC		BIT(13) /* Advanced Virtual Interrupt Controller */

 #define	VMCB_CACHE_DEFAULT	(VMCB_CACHE_ASID 	|	\
 				VMCB_CACHE_IOPM		|	\
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Dirk Engling | 22 Jan 22:11 2015

zero size memset

Dear fellow hackers,

knowing that the memset API tends to be hard to remember from time to
time, I grepped the FreeBSD source for occurences of memset with a
length parameter of 0 and a character parameter that should have been a
length and found the following:

./contrib/gdb/gdb/remote.c:    memset (regs, rs->sizeof_g_packet, 0);
./contrib/gdb/gdb/std-regs.c:  memset (buf, TYPE_LENGTH (VALUE_TYPE
(val)), 0);
./contrib/gdb/gdb/std-regs.c:   memset (buf, TYPE_LENGTH (VALUE_TYPE
(val)), 0);
./contrib/gdb/gdb/std-regs.c:   memset (buf, TYPE_LENGTH (VALUE_TYPE
(val)), 0);

Whom to nudge to have this fixed?

I also grepped the tree for occurences of x = realloc(x ... but found
too many of them to check all instances if they properly abort() when x
is NULL. Does anyone know how to exclude false positives here?

TIA,

  erdgeist
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

(Continue reading)

Sinha, Prokash | 22 Jan 17:18 2015

Re: elf linking problem

I looked at the MODULE_DEPEND, and it is a hint to the kernel, sort of
load ordering ( in other OS terminology).

Here I'm using kldload first to A module, which loads fine, there is a
kernel variable that is defined in the
Kernel space, that I can verify with -
sysctl -b kern.function_list | tr '\0' '\n' | <the symbol>

Now when I do the kldload of the dependent module B, I see these҆

By the way, the module loads works fine on freebsd7.2, I tested them.

So I was thinking if new compiler/ld could have something to do with it ?

-prokash

On 1/22/15 2:38 AM, "Konstantin Belousov" <kostikbel <at> gmail.com> wrote:

>On Thu, Jan 22, 2015 at 01:34:06AM +0000, Sinha, Prokash wrote:
>> I'm forwarding to the kernel group, in case someone can point me to the
>> root of this problem.
>> 
>> Would appreciate any insight !
>> 
>> Thanks,
>> -prokash
>> 
>> kldload: R_X86_64_PC32 retype switch  <--- This is the first failure  (
>> from dmesg )
>> ink_elf_obj: symbol pan_sys_once undefinedELF_RELOC_RELA
(Continue reading)

Matthias Apitz | 21 Jan 13:11 2015
Picon

make installworld/kernel of an amd64 system into an i386 system


Hello,

I actually run on one of my laptops (Acer C720) a very fresh -HEAD
(r276659), but in 32bit; I want to change this to amd64; I produced a
amd64 memstick which boots fine and also has the sources and obj tree which
was used to create the memstick in

	/usr/local/acerc720/src
	/usr/local/acerc720/obj-amd64

What I now think as update procedure to install amd64 into the laptop
is:

- boot the amd64 system from USB
- mount the old i386 root in /dev/ada0p2 as /mnt (there is only this one big
  file system, /dev/ada0p1 is boot and /dev/ada0p3 is swap)
- run
  cd /usr/local/acerc720/src
  MAKEOBJDIRPREFIX=/usr/local/acerc720/obj-amd64 export MAKEOBJDIRPREFIX
  make installworld  DESTDIR=/mnt
  make installkernel DESTDIR=/mnt
  make distrib-dirs  DESTDIR=/mnt
  make distribution  DESTDIR=/mnt
  mv /mnt/usr/local/lib /mnt/usr/local/lib32
  cp /etc/rc.conf  /mnt/etc
  cp /boot/loader.conf /mnt/boot
  echo 'ldconfig32_paths="/usr/lib32 /usr/local/lib32"' >> /mnt/etc/rc.conf
  reboot

(Continue reading)


Gmane