Re: Any concrete plans after the GDB BoF?
anix via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
Dear：
thank you very mach for the program.
the following is description for bug.
# The source code convert between single-precision floating-point(32-bit) and half-precision floating-point (16-bit).
.section .data
m32fp: .float 142, 580, 36832, 65504
half: .short 0x5870, 0x6080, 0x787f, 0x7bff
h1: .short 0, 0 ,0, 0
m1: .float 0, 0, 0, 0
.section .text
.globl _start
_start:
nop
movaps m32fp, %xmm0
vcvtps2ph $0, %xmm0, h1 #imm8=$0; h1 {m64}
vcvtph2ps h1, %xmm1
movups %xmm1, m1
next: movl $1, %eax
movl $0, %ebx
int $0x80
# the source code end here.
# results under GNU Debugger (gdb)
(gdb) x/4fw &m32fp
0x804a000: 142 580 36832 65504
(gdb) x/4fw &m1
0x804a020: 142 580 36832 65504
(gdb) x/4fh &half
0x804a010: 22640 24704 30847 31743
(gdb) x/4fh &h1
0x804a018: 22640 24712 30847 31743
(gdb) x/4xw &m32fp
0x804a000: 0x430e0000 0x44110000 0x470fe000 0x477fe000
(gdb) x/4xw &m1
0x804a020: 0x430e0000 0x44110000 0x470fe000 0x477fe000
(gdb) x/4xh &half
0x804a010: 0x5870 0x6080 0x787f 0x7bff
(gdb) x/4xh &h1
0x804a018: 0x5870 0x6088 0x787f 0x7bff
# the results of half-precision data (half, h1) by gdb are mistakes, or instruct me
# All above under IA-32 , OS is centos (32-bit), GNU as and gdb are also 32-bit.
hope your return.
Niu Wensheng
2023.02.16
---Original---
From: "Joel Brobecker via Gdb"<[email protected]>
Date: Thu, Feb 16, 2023 12:14 PM
To: "Andrew Burgess"<[email protected]>;
Cc: "Joel Brobecker"<[email protected]>;"Luis Machado"<[email protected]>;"Mark Wielaard"<[email protected]>;"Simon Marchi"<[email protected]>;"Simon Marchi via Gdb"<[email protected]>;
Subject: Re: Any concrete plans after the GDB BoF?
> > As long as the the tool is able to do the formatting of a given file
> > using only that one file, the git-hooks are ready. There is a
> > style_checker option which is currently calling a script that does
> > nothing. But if we have some tools that check things such as formatting,
> > copyright header format, etc, it's easy to insert them and reject
> > the commit.
> >
> > The problem is that this arrives too late in the process, IMO, because
> > by then, the review has already gone through. For a formatting issue,
> > one could argue that the change is trivial, and therefore automatically
> > re-approved, but this is not ideal.
>
> Whether the commit should be reformatted and auto-approved is orthogonal
> I think to whether we should have an auto-format checked as part of the
> commit hook.
>
> As long as folk are able to manually push to master then the process is
> open to (honest) user mistakes, and we should, as far as possible aim to
> have systems in place to guard against those mistakes.
>
> So having git refuse to accept a commit that is incorrectly formatted
> would be a good thing; though I 100% agree with you that ideally we
> would ALSO have tools that could auto-check the formatting earlier in
> the process and bring that to the developers attention.
Agreed. If we want to ensure correct formatting, we need to check for it
before the commit gets pushed. The earlier, the better.
> > Good or bad, my concern is that the younger generation views emails
> > as antiquated and at the same time they have grown up learning about
> > collaboration using systems such as GitLab or GitHub.
>
> I'd avoid the word 'antiquated' as it (too me) seems to have negative
> connotations.
I agree with that, and was only using this word in the context of
me putting myself in the shoes of those who shared this feedback
with me. Personally, I love email. But truly, some of the younger
generation I talked to simply do not understand our reluctance to
switch to what they believe to be superior technology. As far as
code collaboration goes, they truly see email as a thing of the past.
Having gone through a transition from email-based review to reviews
through a dedicated system, I have to say that it hurt at first,
but generally speaking, I think it was a huge boost overall.
> But I agree, many developers are familiar with a pull-request
> development model, and I think it has many advantages over our current
> way of doing things, I'd be very much in favour of switching to a PR
> style system.
>
> That doesn't mean there aren't also advantages to how we do things
> today.
Agreed also.
--
Joel