headers
mdf | 1 Jun 2011 01:07
Picon
Favicon

sizeof(function pointer)

I am looking into potentially MFC'ing r212367 and related, that adds
drains to sbufs.  The reason for MFC is that several pieces of new
code in CURRENT are using the drain functionality and it would make
MFCing those changes much easier.

The problem is that r212367 added a pointer to a drain function in the
sbuf (it replaced a pointer to void).  The C standard doesn't
guarantee that a void * and a function pointer have the same size,
though its true on amd64, i386 and I believe PPC.  What I'm wondering
is, though not guaranteed by the standard, is it *practically* true
that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't
break binary compatibility for any supported architecture?  (The
standard does guarantee, though not in words, that all function
pointers have the same size, since it guarantees that pointers to
functions can be cast to other pointers to functions and back without
changing the value).

Another possibility is to malloc a blob that is sizeof(int(*)(void))
and store that in a renamed s_unused; this is a bit messier but
guaranteed to work.  I'd just rather the code be an MCF instead of a
partial re-write.

Thanks,
matthew
_______________________________________________
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)

Permalink | Reply | 10 comments |
headers
Warner Losh | 1 Jun 2011 01:18

Re: sizeof(function pointer)


On May 31, 2011, at 5:07 PM, mdf <at> freebsd.org wrote:

> I am looking into potentially MFC'ing r212367 and related, that adds
> drains to sbufs.  The reason for MFC is that several pieces of new
> code in CURRENT are using the drain functionality and it would make
> MFCing those changes much easier.
> 
> The problem is that r212367 added a pointer to a drain function in the
> sbuf (it replaced a pointer to void).  The C standard doesn't
> guarantee that a void * and a function pointer have the same size,
> though its true on amd64, i386 and I believe PPC.  What I'm wondering
> is, though not guaranteed by the standard, is it *practically* true
> that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't
> break binary compatibility for any supported architecture?  (The
> standard does guarantee, though not in words, that all function
> pointers have the same size, since it guarantees that pointers to
> functions can be cast to other pointers to functions and back without
> changing the value).
> 
> Another possibility is to malloc a blob that is sizeof(int(*)(void))
> and store that in a renamed s_unused; this is a bit messier but
> guaranteed to work.  I'd just rather the code be an MCF instead of a
> partial re-write.

It is the same on MIPS too for all three ABIs that we support (and all ABIs that I know about).  It is true on ARM as well.

Usually it is different only on segmented architectures like 16-bit x86.

Warner_______________________________________________
(Continue reading)

Permalink | Reply | 5 comments |
headers
Dieter BSD | 1 Jun 2011 01:38

Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes)

>> please keep in mind that -Wfoo does reflect the ideas of the GNU people
>> regarding *proper* code. the warnings themselves are sometimes wrong,
>> because they complain about perfectly correct code.

I attempted to get the gcc people to improve this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072

Most of the warnings I see are either due to someone thinking
all the world is ILP32 and doing things like storing a 64 bit
pointer or long in a 32 bit int, or due to the compiler needing
more info to insure that they are not trying to stuff 64 bits into
32, such as missing prototypes.  Either way it needs to be fixed.

In many cases the developers that claim to write such great code,
and claim that the compiler warnings don't matter are the ones
whose code has the most bugs (seg faults, floating point exceptions, ...).

> Pretty much the entire kernel is compiled
> with quite a large number of warning classes enabled, and -Werror set, for
> example.

Whoever did this, THANK YOU!!!

> fixing warnings in other people's code is useful only if
> you can get them to accept the fixes back

Fixing bugs is always useful.  Certainly it is a *lot* more
efficient if you can get them fixed at the source rather than
having to maintain patches.
_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dieter BSD | 1 Jun 2011 01:45

Re: Active slice, only for a next boot

Peter writes:

>> A better approach is to be able to boot whatever slice you
>> want without having to change the active slice.
>>
>> NetBSD can do this. The MBR puts up a menu of the bootable
>> slices on the disk being booted. You can allow the timer
>> to time out and boot the default. Or you can enter the number
>> of the slice you want to boot. Or you can type a function key
>> F1 F2 ... to boot a different disk, and it will load the MBR
>> from that disk and run it. There is an alternative for keyboards
>> without function keys.

> So can FreeBSD - though only for MBR

If so, the documentation could use improvement.
Examples would be great.

> - this functionality doesn't seem
> to have made it into the GPT bootcode.

Is anyone working on this?  MBR is only good for 2 TB
and the 3 TB disks are becoming cost competitive.  I've
switched over to GPT for everything except boot disks,
as it is less brain damaged than MBR.

>> And it works great. Except that one of the 27 stages of boot
>> code that FreeBSD uses INSISTS on booting the active slice,
>> so you can tell the MBR to boot slice 3 and slice 3's boot
>> code sees that slice 4 is active and boots slice 4.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Kabaev | 1 Jun 2011 02:06
Picon

Re: sizeof(function pointer)

On Tue, 31 May 2011 17:18:16 -0600
Warner Losh <imp <at> bsdimp.com> wrote:

> 
> On May 31, 2011, at 5:07 PM, mdf <at> freebsd.org wrote:
> 
> > I am looking into potentially MFC'ing r212367 and related, that adds
> > drains to sbufs.  The reason for MFC is that several pieces of new
> > code in CURRENT are using the drain functionality and it would make
> > MFCing those changes much easier.
> > 
> > The problem is that r212367 added a pointer to a drain function in
> > the sbuf (it replaced a pointer to void).  The C standard doesn't
> > guarantee that a void * and a function pointer have the same size,
> > though its true on amd64, i386 and I believe PPC.  What I'm
> > wondering is, though not guaranteed by the standard, is it
> > *practically* true that sizeof(void *) == sizeof(int(*)(void)),
> > such that an MFC won't break binary compatibility for any supported
> > architecture?  (The standard does guarantee, though not in words,
> > that all function pointers have the same size, since it guarantees
> > that pointers to functions can be cast to other pointers to
> > functions and back without changing the value).
> > 
> > Another possibility is to malloc a blob that is sizeof(int(*)(void))
> > and store that in a renamed s_unused; this is a bit messier but
> > guaranteed to work.  I'd just rather the code be an MCF instead of a
> > partial re-write.
> 
> It is the same on MIPS too for all three ABIs that we support (and
> all ABIs that I know about).  It is true on ARM as well.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Nathan Whitehorn | 1 Jun 2011 01:41
Picon
Favicon

Re: sizeof(function pointer)

On 05/31/11 18:18, Warner Losh wrote:
> On May 31, 2011, at 5:07 PM, mdf <at> freebsd.org wrote:
>
>> I am looking into potentially MFC'ing r212367 and related, that adds
>> drains to sbufs.  The reason for MFC is that several pieces of new
>> code in CURRENT are using the drain functionality and it would make
>> MFCing those changes much easier.
>>
>> The problem is that r212367 added a pointer to a drain function in the
>> sbuf (it replaced a pointer to void).  The C standard doesn't
>> guarantee that a void * and a function pointer have the same size,
>> though its true on amd64, i386 and I believe PPC.  What I'm wondering
>> is, though not guaranteed by the standard, is it *practically* true
>> that sizeof(void *) == sizeof(int(*)(void)), such that an MFC won't
>> break binary compatibility for any supported architecture?  (The
>> standard does guarantee, though not in words, that all function
>> pointers have the same size, since it guarantees that pointers to
>> functions can be cast to other pointers to functions and back without
>> changing the value).
>>
>> Another possibility is to malloc a blob that is sizeof(int(*)(void))
>> and store that in a renamed s_unused; this is a bit messier but
>> guaranteed to work.  I'd just rather the code be an MCF instead of a
>> partial re-write.
> It is the same on MIPS too for all three ABIs that we support (and all ABIs that I know about).  It is true on ARM
as well.
>
> Usually it is different only on segmented architectures like 16-bit x86.

It is also true on ARM, PPC, PPC64, and ia64, which I just tested. I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nathan Whitehorn | 1 Jun 2011 03:19
Picon
Favicon

Re: sizeof(function pointer)

On 05/31/11 19:06, Alexander Kabaev wrote:
> On Tue, 31 May 2011 17:18:16 -0600
> Warner Losh<imp <at> bsdimp.com>  wrote:
>
>> On May 31, 2011, at 5:07 PM, mdf <at> freebsd.org wrote:
>>
>>> I am looking into potentially MFC'ing r212367 and related, that adds
>>> drains to sbufs.  The reason for MFC is that several pieces of new
>>> code in CURRENT are using the drain functionality and it would make
>>> MFCing those changes much easier.
>>>
>>> The problem is that r212367 added a pointer to a drain function in
>>> the sbuf (it replaced a pointer to void).  The C standard doesn't
>>> guarantee that a void * and a function pointer have the same size,
>>> though its true on amd64, i386 and I believe PPC.  What I'm
>>> wondering is, though not guaranteed by the standard, is it
>>> *practically* true that sizeof(void *) == sizeof(int(*)(void)),
>>> such that an MFC won't break binary compatibility for any supported
>>> architecture?  (The standard does guarantee, though not in words,
>>> that all function pointers have the same size, since it guarantees
>>> that pointers to functions can be cast to other pointers to
>>> functions and back without changing the value).
>>>
>>> Another possibility is to malloc a blob that is sizeof(int(*)(void))
>>> and store that in a renamed s_unused; this is a bit messier but
>>> guaranteed to work.  I'd just rather the code be an MCF instead of a
>>> partial re-write.
>> It is the same on MIPS too for all three ABIs that we support (and
>> all ABIs that I know about).  It is true on ARM as well.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
perryh | 1 Jun 2011 04:50

Re: Active slice, only for a next boot

"Dieter BSD" <dieterbsd <at> engineer.com> wrote:

> If you neglected to specify RS-232 console in the requirements,
> there is this thing. ??I haven't tried it.
> http://www.realweasel.com/

Heard of it, aka the PC Weasel.  I've never actually seen one.  They
have been around for a while; the original -- which they apparently
still make -- was ISA.

> Somebody probably sells a KVM-over-IP box.

Raritan, at least.  Probably others also.

> > Unfortunately it doesn't have a better way to do this as the
> > only input it gets from boot0 or any other MBR boot loader is
> > the BIOS drive number in %dl.  I'm not sure how else you would
> > detect that a non-active slice was booted from when that is
> > your only input.
>
> The NetBSD boot code manages to do it.

Dunno how NetBSD does it, but one approach that comes to mind would
be for whatever installs boot1 to set one of its bytes to the slice
number in which it is installed.
_______________________________________________
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)

Permalink | Reply | 0 comments |
headers
Marcel Moolenaar | 1 Jun 2011 06:09

Re: sizeof(function pointer)


On May 31, 2011, at 5:06 PM, Alexander Kabaev wrote:
>> Usually it is different only on segmented architectures like 16-bit
>> x86.
>> 
> 
> Not so on ia64, where they have special function descriptor type.

Actually, no. On ia64 a function pointer has the same size as a
data pointer. It's just that a function pointer does not point
to the actual function (i.e. the first instruction of a function),
but to a function descriptor. The function descriptor contains the
address of the actual function and the value of the GP register
that needs to be set before entering the function.

As such, only virtual functions in C++ are impacted by this. The
function descriptor needs to be stored in the object instead of
the function pointer in that case.

FYI,

--

-- 
Marcel Moolenaar
marcel <at> xcllnt.net

_______________________________________________
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)

Permalink | Reply | 1 comment |
headers
Andriy Gapon | 1 Jun 2011 07:40
Picon
Favicon

Re: [RFC] Enabling invariant TSC timecounter on SMP

on 31/05/2011 23:16 Jung-uk Kim said the following:
> On Tuesday 31 May 2011 07:18 am, Andriy Gapon wrote:
>> on 24/05/2011 20:56 Jung-uk Kim said the following:
>>> I think it's about time to enable invariant TSC timecounter on
>>> SMP by default.  Please see the attached patch.  It is also
>>> available from here:
>>>
>>> http://people.freebsd.org/~jkim/tsc_smp_test4.diff
>>>
>>> avg convinced me enough that it should be an opt-out feature
>>> going forward. :-)
>>
>> Not sure if I really did that.
>> My position is this:
>> - if we think that TSC is SMP-safe then it should have the best
>> priority
>> - we should do our best to auto-guess if TSC is SMP-safe 
>> unless a user explicitly overrides that property (either via
>> explicit testing or by making guesses based on CPU model or etc)
> 
> I am sorry if I misunderstood your intention.  However, I added 
> explicit boot-time TSC sanity check (to do our best to auto-guess) 
> and I think TSC is fairly SMP-safe.  Hence, I thought that it is 
> about time for the change.

In this case - yes.  But I remember that you were thinking about either
improving or simplifying that check or both.

>>> Comments?
>>
(Continue reading)

Permalink | Reply | 6 comments |

Gmane