Jan Beulich wrote:
~
gcc can do long long multiplies fine, but only with a long long result.
The code presented, however, needs (at least) 96 bits of the result,
which expressing in C would be far more complicated than doing it with a
couple of assembly statements.
Well, if you need that many bits... guess I would need to study the code (hard with binary
attachments) to understand why you need so many bits.
I really do not see the relavence of the run time library patches
~
Which run time library patches are you referring to? NLKD's? If so,
these routines must not be used by code outside of the debugger (and the
opposite is true, too: debugger code must not use common code routines
where ever possible).
Just what is your argument here? As I understand it this is only a problem (i.e. sharing the code)
if you are trying to single step or set breakpoints in the library code.
Further, it is my understanding that it is for a (unknown to me) reason
that the linux kernel doesn't have the full set of libgcc support
routines. Since the debugger in various places relies on being able to
do 64-bit math on 32-bit systems, I had to add these in a way so that
they'd be hidden from the rest of the kernel (and also so that they'd
satisfy the isolation rules outlined above).
Well, the powers that be, decided that the kernel did not need the "missing" routines and that they
just added bloat. One then wonders why a debugger needs them. Could you enlighten us on this?
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
