Linux-Development-Sys Digest #8, Volume #8 Mon, 10 Jul 00 18:13:22 EDT
Contents:
unresolved symbol __builtin_vec_new? ([EMAIL PROTECTED])
Re: How to port MSVC++ app to Linux? ("Dennis Bijwaard")
Re: sizeof() in gcc (Kaz Kylheku)
Re: unresolved symbol __builtin_vec_new? (Kaz Kylheku)
Re: sizeof() in gcc (Grant Edwards)
Re: keyboard with additional function keys ("LY")
Re: keyboard with additional function keys (B'ichela)
Re: sizeof() in gcc ("Ross Smith")
Re: sizeof() in gcc ("Ross Smith")
Re: unresolved symbol __builtin_vec_new? ([EMAIL PROTECTED])
Re: sizeof() in gcc (Erik Max Francis)
Re: Interrupt handling in Linux ("Nick Lahtinen")
Re: Interrupt handling in Linux (Kaz Kylheku)
Re: sizeof() in gcc (Kaz Kylheku)
Re: unresolved symbol __builtin_vec_new? (Kaz Kylheku)
Re: sizeof() in gcc (Grant Edwards)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: unresolved symbol __builtin_vec_new?
Date: Mon, 10 Jul 2000 18:59:12 GMT
Hi,
Can anyone solve the "unresolved symbol __builtin_vec_new and
__builtin_vec_delete"?
I just want to use the following statements:
short *ptr;
int len;
ptr = new short[len];
and, delete [] ptr;
I must new the array in runtime because the length is assigned
dynamically. After I load my module, and it will appear unresolved
symbols I mentioned above.
I implemented the new and delete operator by myself, and compiled it by
g++ -fno-exceptions -fno-builtin -D__KERNEL__ -DMODULE.
Should I put some option or miss something?
Thanks for your kindly help.
- Sam
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Dennis Bijwaard" <[EMAIL PROTECTED]>
Subject: Re: How to port MSVC++ app to Linux?
Date: 10 Jul 2000 19:24:16 GMT
Gene Montgomery <[EMAIL PROTECTED]> wrote:
> I would appreciate hearing any tips regarding porting MS-dependent code
> to the Linux/GNU world, or a steer to a web site with such information.
Did you actually try to compile it under linux?
When it does not compile, check where it breaks and fix it.
When you're talking about a console application, you've got a good change
to get it ported without much trouble.
When it complains about unavailable functions during linking, you'll have
to go search for them (e.g. do man <function> to see if it exists and try
to include the header file in which it is defined, or try
grep <function> /usr/include/*.h).
--
Vriendelijke groet,
Dennis Bijwaard (remove antispam to reply)
http://people.a2000.nl/dbijwaar
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: sizeof() in gcc
Reply-To: [EMAIL PROTECTED]
Date: Mon, 10 Jul 2000 19:28:25 GMT
On Mon, 10 Jul 2000 17:25:35 GMT, Norm Dresner <[EMAIL PROTECTED]> wrote:
>
>There are obviously many other ways to perform the same check, but we felt
>that doing this at compile-time would make the system the most robust
>against unintentional changes later. I agree that sizeof() is a C-operator,
>but when the Borland-C implementation had it I thought (obviously
>incorrectly) that I could also use it in the Linux version.
Should have checked the ANSI C standard to see whether you are relying on a
compiler extension or a standard feature.
It also helps to always operate your compiler in an ANSI C mode in which it
emits the required diagnostics, e.g. ``line 3 warning: sizeof in preprocessor
directive is not an ANSI feature''. If the language extension is conforming
(that is, does not require any valid ANSI C programs to be mistranslated or
rejected) then it can still be available despite the diagnostic message.
Otherwise, you have no control over what language your developers are actually
programming in. Is it C or is it Borland C? Microsoft C? GNU C? ;)
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: unresolved symbol __builtin_vec_new?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 10 Jul 2000 19:37:35 GMT
On Mon, 10 Jul 2000 18:59:12 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>Hi,
>
>Can anyone solve the "unresolved symbol __builtin_vec_new and
>__builtin_vec_delete"?
This happens because the kernel doesn't have support for C++ programming.
>I just want to use the following statements:
>
>short *ptr;
>int len;
>ptr = new short[len];
>and, delete [] ptr;
To use operator new in the kernel, you must write your own file scope overload
in terms of kmalloc.
I suggest an overload which allows you to use the placement syntax to specify
the kmalloc flags:
void *operator new (size_t size, int flags = GFP_KERNEL)
{
return kmalloc(size, flags);
}
void operator delete (void *ptr)
{
kfree(ptr);
}
Another problem is that you are calling operator new from file scope. Loading
a dynamic module will not cause global C++ initializations in that module to be
performed, so do not rely on them. Use only C style static initialization: that
is to say, use only constant expressions to initialize objects or aggregate
members.
Also note that the use of C++ keywords as identifiers is rampant in Linux
header files. To remedy that problem, create a header which uses macros to
rename all the C++ keywords to some safe identifiers, and another header which
#undef's these macros. Then you can do:
#include "cppwrap.h"
// Include kernel headers here
#include "parwpcc.h"
The cppwrap.h file would contain, e.g:
#define class CPP_class
#define virtual CPP_virtual
#define namespace CPP_namespace
// ... repeat for all C++ keywords
The opposite, parwpcc.h would contain:
#undef class
#undef virtual
// ...
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: sizeof() in gcc
Date: Mon, 10 Jul 2000 19:50:04 GMT
In article <jGna5.4100$[EMAIL PROTECTED]>, Norm Dresner
wrote:
>I truth, in the original -- unsimplified -- file, the sizeof() operator was
>used (in Borland C) to verify that two different data structures would, when
>combined in any order, yield the same memory layout, i.e. that two different
>ways of setting up the FIFOs in a communications channel would ultimately
>take the same space so the memory could be pre-allocated and the user could
>dynamically define the channel's characteristics.
I've resorted to other (slightly obtuse) ways to verify object
sizes at compile time.
char bogusNeverUsedArray[ sizeof foo == sizeof bar];
The above code will (on most compilers) generate a compile time
error or warning if the sizes of objects foo and bar aren't the
same. Use the --pedantic option with gcc to get the desired
effect (by default gcc allows zero length arrays).
The downside:
1) You have to put in comments so that somebody else can tell
WTH you're trying to accomplish.
2) It uses up a byte of memory.
3) If it only generates a warning (as gcc does) you've got to
actually look at the "make" output...
--
Grant Edwards grante Yow! I had pancake makeup
at for brunch!
visi.com
------------------------------
From: "LY" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.development,comp.os.linux.hardware
Subject: Re: keyboard with additional function keys
Date: Mon, 10 Jul 2000 21:47:20 +0200
Thanx for the information, but I still have the problem. I've mentioned that
if I press a key that I'll get a sequence of scancodes e.g. scancode for the
number "4" is 0x85, after pressing the additional function key I get 0x85
0x85. I can't work with this sequence of scancodes, because it's not unique.
However, thanx for the information!!!
------------------------------
From: [EMAIL PROTECTED] (B'ichela)
Crossposted-To:
comp.os.linux.development.apps,comp.os.linux.development,comp.os.linux.hardware
Subject: Re: keyboard with additional function keys
Date: Mon, 10 Jul 2000 15:58:22 -0400
Reply-To: [EMAIL PROTECTED]
On Mon, 10 Jul 2000 19:12:35 +0200, LY <[EMAIL PROTECTED]> wrote:
>Hi!
>
>Can someone help me!
>
>I have a keyboard with about 30 additional function keys. If I press one key
>it gives me for example a double "4" or "a" ... (44, aa, ...). It means that
>I get double scancodes. These parts of this sequence of scancodes are the
>same and they are known.
>Do someone know how to change this sequence of double scancodes in a unique
>scancode? Or can somebody write a program for solving this problem?
>
>If someone can really solve this problem, then please contact me!!! I would
>give a little pocket money (allowance)!
Hmm. Who makes your keyboard? what is the model number of this
keyboard? Are you using it under X or the Text based system?
--
B'ichela
------------------------------
From: "Ross Smith" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: sizeof() in gcc
Date: Tue, 11 Jul 2000 08:40:35 +1200
"Norm Dresner" <[EMAIL PROTECTED]> wrote in message
news:%Yma5.4066$[EMAIL PROTECTED]...
> I'm getting a "parse error" on the (simplified) line
> #if ( sizeof(int) ) != 4
>
> Is this really illegal?
Yes. Sizeof is only available at compile time, not in the
preprocessor.
> Is there any other way to do size comparisons in the pre-processor?
#include <ctype.h>
#if INT_MAX >= 0x7FFFFFFF
--
Ross Smith <[EMAIL PROTECTED]> The Internet Group, Auckland, New Zealand
========================================================================
"C++ is to programming as sex is to reproduction. Better ways might
technically exist but they're not nearly as much fun." -- Nikolai Irgens
------------------------------
From: "Ross Smith" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: sizeof() in gcc
Date: Tue, 11 Jul 2000 08:41:53 +1200
"Ross Smith" <[EMAIL PROTECTED]> wrote in message news:8kdcc8$pf2$[EMAIL PROTECTED]...
> "Norm Dresner" <[EMAIL PROTECTED]> wrote in message
>news:%Yma5.4066$[EMAIL PROTECTED]...
> > I'm getting a "parse error" on the (simplified) line
> > #if ( sizeof(int) ) != 4
> >
> > Is this really illegal?
>
> Yes. Sizeof is only available at compile time, not in the
> preprocessor.
>
> > Is there any other way to do size comparisons in the pre-processor?
>
> #include <ctype.h>
> #if INT_MAX >= 0x7FFFFFFF
Doh! That should be <limits.h>, of course.
--
Ross Smith <[EMAIL PROTECTED]> The Internet Group, Auckland, New Zealand
========================================================================
"C++ is to programming as sex is to reproduction. Better ways might
technically exist but they're not nearly as much fun." -- Nikolai Irgens
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: unresolved symbol __builtin_vec_new?
Date: Mon, 10 Jul 2000 20:44:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Mon, 10 Jul 2000 18:59:12 GMT, [EMAIL PROTECTED] <samhsieh@my-
deja.com>
> wrote:
> >Hi,
> >
> >Can anyone solve the "unresolved symbol __builtin_vec_new and
> >__builtin_vec_delete"?
>
> This happens because the kernel doesn't have support for C++
programming.
>
> >I just want to use the following statements:
> >
> >short *ptr;
> >int len;
> >ptr = new short[len];
> >and, delete [] ptr;
>
> To use operator new in the kernel, you must write your own file scope
overload
> in terms of kmalloc.
>
> I suggest an overload which allows you to use the placement syntax to
specify
> the kmalloc flags:
>
> void *operator new (size_t size, int flags = GFP_KERNEL)
> {
> return kmalloc(size, flags);
> }
>
> void operator delete (void *ptr)
> {
> kfree(ptr);
> }
>
This new operator is only used by initializing an instance, like new
myClass(), but not for the case I mentioned. When I called new char
[len], it will try to call the builtin function __builtin_vec_new,
which is a 'vector' new operator. I don't know what's the difference
between __builtin_new and __builtin_vec_new.
So, the problem is still there. Can I solve the unsolved symbols of
__builtin_vec_new and __builtin_vec_delete.
> Another problem is that you are calling operator new from file
scope. Loading
> a dynamic module will not cause global C++ initializations in that
module to be
> performed, so do not rely on them. Use only C style static
initialization: that
> is to say, use only constant expressions to initialize objects or
aggregate
> members.
>
> Also note that the use of C++ keywords as identifiers is rampant in
Linux
> header files. To remedy that problem, create a header which uses
macros to
> rename all the C++ keywords to some safe identifiers, and another
header which
> #undef's these macros. Then you can do:
>
> #include "cppwrap.h"
>
> // Include kernel headers here
>
> #include "parwpcc.h"
>
> The cppwrap.h file would contain, e.g:
>
> #define class CPP_class
> #define virtual CPP_virtual
> #define namespace CPP_namespace
> // ... repeat for all C++ keywords
>
> The opposite, parwpcc.h would contain:
>
> #undef class
> #undef virtual
> // ...
>
Anyway, thanks for your help.
> --
> #exclude <windows.h>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: sizeof() in gcc
Date: Mon, 10 Jul 2000 14:07:01 -0700
Kaz Kylheku wrote:
> On Mon, 10 Jul 2000 17:25:35 GMT, Norm Dresner <[EMAIL PROTECTED]> wrote:
>
> > I agree that sizeof() is a
> > C-operator,
> > but when the Borland-C implementation had it I thought (obviously
> > incorrectly) that I could also use it in the Linux version.
>
> Should have checked the ANSI C standard to see whether you are relying
> on a
> compiler extension or a standard feature.
Back when I was using Borland compilers, I found this to be something of
a problem. Borland's reference manuals were fairly extensive, but often
didn't make it clear when a feature was standard or was a compiler
extension. I recall several times moving on in life thinking that
such-and-such a feature was standard because the Borland documentation
said it was, only to find out that it in fact wasn't.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Life is something to do when you can't get to sleep.
\__/ Fran Lebowitz
Physics reference / http://www.alcyone.com/max/reference/physics/
A physics reference.
------------------------------
From: "Nick Lahtinen" <[EMAIL PROTECTED]>
Subject: Re: Interrupt handling in Linux
Date: Mon, 10 Jul 2000 14:57:19 -0600
Kaz Kylheku wrote in message ...
>
>So what are you making, kernel extensions or an application?
>
>The serial system in Linux already handles interrupts, and performs
buffering
>and flow control and all that. All you have to do in user space is open
>up the serial device like /dev/ttyS0, use the POSIX termios interfaces to
>configure its settings and just perform your data transfers.
>
>Multiplexing a whole lot of serial ports can be done with poll(), select()
>or multiple threads. The unblocking of reads, writes or polls is keyed to
the
>reception of interrupts.
>
>--
>#exclude <windows.h>
I guess the problem that I'm trying to address is that the communication in
this application that I'm working on is completely asynchronous and comes
into the port in blocks that need to be handled separately, but I think I
might have some ideas about where to start, but I guess I just need to
figure out the buffering system in Linux, and how incoming data is
structured. Your help is still appreciated.
Nick
_________________________________________________-
#exclude <windows.h> // What a good idea!!! :-)
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Interrupt handling in Linux
Reply-To: [EMAIL PROTECTED]
Date: Mon, 10 Jul 2000 21:42:55 GMT
On Mon, 10 Jul 2000 14:57:19 -0600, Nick Lahtinen <[EMAIL PROTECTED]> wrote:
>
>I guess the problem that I'm trying to address is that the communication in
>this application that I'm working on is completely asynchronous and comes
>into the port in blocks that need to be handled separately, but I think I
That is an unfortunate, amateurish error in the design of the data link
protocol. Units of data have to be properly delimited when juxtaposed in a
serial stream. The various communication points cannot be expected to rely on
timing to separate the messages.
If the blocks themselves have any sort of structure that can help separate the
stream into frames, I suggest you take advantage of that. Otherwise, if you
have control over the format of the protocol, I suggest you introduce framing
bytes, using the same scheme as what is used by the point-to-point protocol.
>might have some ideas about where to start, but I guess I just need to
>figure out the buffering system in Linux, and how incoming data is
>structured.
It's not structured at all; it just fills a buffer which flips when it
gets full.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: sizeof() in gcc
Reply-To: [EMAIL PROTECTED]
Date: Mon, 10 Jul 2000 21:50:56 GMT
On Mon, 10 Jul 2000 19:50:04 GMT, Grant Edwards <[EMAIL PROTECTED]> wrote:
>I've resorted to other (slightly obtuse) ways to verify object
>sizes at compile time.
>
>char bogusNeverUsedArray[ sizeof foo == sizeof bar];
>
>The above code will (on most compilers) generate a compile time
>error or warning if the sizes of objects foo and bar aren't the
>same. Use the --pedantic option with gcc to get the desired
>effect (by default gcc allows zero length arrays).
The trick is to rewrite the compile-time assert so that if the condition
is false, it generates an array having negative length. Then it will
work even if zero length array declarations are allowed.
The credits for teaching me this trick go to Chris Torek of BSDI, Inc.
#define compile_time_assert(X) { typedef int bogus[2 - 2*((X) == 0)]; }
You might be tempted to use the ternary operator, but note that
a ternary expression is not considered constant by ANSI C. So the
following would not work:
typedef int bogus[((X) == 0) ? -1 : 0]; /* error, not constant! */
>The downside:
>
> 1) You have to put in comments so that somebody else can tell
> WTH you're trying to accomplish.
>
> 2) It uses up a byte of memory.
That's only because it's an object definition. Change it to a typedef
and it reserves no storage.
> 3) If it only generates a warning (as gcc does) you've got to
> actually look at the "make" output...
With gcc, you can use -pedantic-errors to take care of that one.
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: unresolved symbol __builtin_vec_new?
Reply-To: [EMAIL PROTECTED]
Date: Mon, 10 Jul 2000 21:54:21 GMT
On Mon, 10 Jul 2000 20:44:45 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>> I suggest an overload which allows you to use the placement syntax to
>specify
>> the kmalloc flags:
>>
>> void *operator new (size_t size, int flags = GFP_KERNEL)
>> {
>> return kmalloc(size, flags);
>> }
>>
>> void operator delete (void *ptr)
>> {
>> kfree(ptr);
>> }
>>
>This new operator is only used by initializing an instance, like new
>myClass(), but not for the case I mentioned. When I called new char
>[len], it will try to call the builtin function __builtin_vec_new,
>which is a 'vector' new operator. I don't know what's the difference
>between __builtin_new and __builtin_vec_new.
The difference is that one is used for new [] and the other is used
for new. These two operators are distinct, and the structure of the
allocated object may actually differ.
>So, the problem is still there. Can I solve the unsolved symbols of
>__builtin_vec_new and __builtin_vec_delete.
Then why don't you also write your own overrides for operators new[] and
delete[]?
--
#exclude <windows.h>
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: sizeof() in gcc
Date: Mon, 10 Jul 2000 22:07:15 GMT
In article <[EMAIL PROTECTED]>, Kaz Kylheku wrote:
>>The above code will (on most compilers) generate a compile time
>>error or warning if the sizes of objects foo and bar aren't the
>>same. Use the --pedantic option with gcc to get the desired
>>effect (by default gcc allows zero length arrays).
>
>The trick is to rewrite the compile-time assert so that if the condition
>is false, it generates an array having negative length. Then it will
>work even if zero length array declarations are allowed.
>
>The credits for teaching me this trick go to Chris Torek of BSDI, Inc.
>
>#define compile_time_assert(X) { typedef int bogus[2 - 2*((X) == 0)]; }
That's clever -- I like that. (The compiler I was using when I
came up the the previous hack didn't allow zero length arrays,
so I never had to go the next step.)
>That's only because it's an object definition. Change it to a typedef
>and it reserves no storage.
Also very clever.
--
Grant Edwards grante Yow! I guess it was all a
at DREAM... or an episode of
visi.com HAWAII FIVE-O...
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
