On Thu, Sep 12, 2013 at 5:39 PM, Dave Jones wrote:
> On Wed, Sep 11, 2013 at 08:46:33AM +0200, Florian Weimer wrote:
>
> > This is the offending function:
> >
> > void
> > cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> > unsigned int *edx)
> > {
> > __asm volatile
On 09/13/2013 10:12 AM, Dridi Boukelmoune wrote:
Actually, this morning (in the train) I've tested your code with my
tmp variable and it works if I remove the deref!
Yes, that should work as well, because the value itself is an output
register.
mov %%ebx, %1
(btw, what do %1 and %4 mean ?)
The issue has been solved by my reviewer, so thank you all because as
usual I've learned interesting things :)
Comments inlined.
On Thu, Sep 12, 2013 at 2:53 PM, Florian Weimer wrote:
> On 09/12/2013 02:11 PM, Dridi Boukelmoune wrote:
>
>>> This version should work in 32 bit mode, and only in 32
On Wed, Sep 11, 2013 at 08:46:33AM +0200, Florian Weimer wrote:
> This is the offending function:
>
> void
> cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
> unsigned int *edx)
> {
> __asm volatile
> ("cpuid\n\t"
> : "=a" (*eax),
>"=b" (*ebx),
On 09/12/2013 02:53 PM, Florian Weimer wrote:
By the way, we could generate much better code if the registers were
passed as an array or struct, so that they are in consecutive memory:
struct regs {
unsigned eax, ebx, ecx, edx;
};
void
cpuid(struct regs *r)
{
__asm volatile
("push %
On 09/12/2013 02:11 PM, Dridi Boukelmoune wrote:
This version should work in 32 bit mode, and only in 32 bit mode:
void
cpuid(unsigned int *eax, unsigned int *ebx, unsigned int *ecx,
unsigned int *edx)
{
__asm volatile
("push %%ebx\n\t"
"cpuid\n\t"
"mov %%ebx, (%1)\n\
On 09/12/2013 02:11 PM, Dridi Boukelmoune wrote:
I don't understand the last 5 lines of __asm in both functions, I've
never seen this syntax before.
It's gcc's extended asm syntax (Aka. "inline asm in C"):
c.f. http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html ff.
Ralf
--
devel mailing
Hi,
On Wed, Sep 11, 2013 at 8:46 AM, Florian Weimer wrote:
> On 09/11/2013 12:31 AM, Dridi Boukelmoune wrote:
>
>> I have my first packaging issue on the numatop package[1].
>>
>> During the review it appeared that I forgot the %{optflags}, and that
>> adding them breaks the i686 build. The upstr
On 09/11/2013 12:31 AM, Dridi Boukelmoune wrote:
I have my first packaging issue on the numatop package[1].
During the review it appeared that I forgot the %{optflags}, and that
adding them breaks the i686 build. The upstream dev is very patient
and willing to help me, but I feel I have wasted
On Wed, 11 Sep 2013 00:31:12 +0200
Dridi Boukelmoune wrote:
> Hi,
>
> I have my first packaging issue on the numatop package[1].
>
> During the review it appeared that I forgot the %{optflags}, and that
> adding them breaks the i686 build. The upstream dev is very patient
> and willing to help
Hi,
I have my first packaging issue on the numatop package[1].
During the review it appeared that I forgot the %{optflags}, and that
adding them breaks the i686 build. The upstream dev is very patient
and willing to help me, but I feel I have wasted enough of his time.
The guilty gcc flag seems
11 matches
Mail list logo
