Since i386 time handling is not overflow-safe, these are the
adjustments needed for allowing debuggers to update time after
having halted the system for perhaps extended periods of time.
Signed-Off-By: Jan Beulich <[email protected]>
(actual patch attached)
Jan Beulich wrote:
> Since i386 time handling is not overflow-safe, these are the
> adjustments needed for allowing debuggers to update time after
> having halted the system for perhaps extended periods of time.
>
> Signed-Off-By: Jan Beulich <[email protected]>
>
> (actual patch attached)
The patch includes code that seems to imply that gcc can not do mpy of (long long) variables. It
does just fine with these. It also adds (long long) types just fine. The only problem it has is
with div, for which we have do_div().
I really do not see the relavence of the run time library patches given the above. The adjust code
does not seem to use them. Also, gcc (with the lib code) does all of this stuff. The only need for
it would, possibly, be to debug the library code and even then, I suspect you really want to do that
in user land and then bring the result into the kernel.
Am I missing something?
>
--
George Anzinger [email protected]
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
>>> George Anzinger <[email protected]> 09.11.05 20:10:09 >>>
>Jan Beulich wrote:
>> Since i386 time handling is not overflow-safe, these are the
>> adjustments needed for allowing debuggers to update time after
>> having halted the system for perhaps extended periods of time.
>>
>> Signed-Off-By: Jan Beulich <[email protected]>
>>
>> (actual patch attached)
>
>The patch includes code that seems to imply that gcc can not do mpy of
(long long) variables. It
>does just fine with these. It also adds (long long) types just fine.
The only problem it has is
>with div, for which we have do_div().
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.
>I really do not see the relavence of the run time library patches
given the above. The adjust code
>does not seem to use them. Also, gcc (with the lib code) does all of
this stuff. The only need for
>it would, possibly, be to debug the library code and even then, I
suspect you really want to do that
>in user land and then bring the result into the kernel.
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).
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).
Jan
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/