Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[jsoe0708]

>-- Original Message --
>To: Joel Soete <joel.soete@freebel.net>
>Cc: John David Anglin <dave@hiauly1.hia.nrc.ca>, jsoe0708@tiscali.be,
>	parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb
>
>From: Grant Grundler <grundler@dsl2.external.hp.com>
>Date: Sat, 31 Aug 2002 17:50:15 -0600
>
>
>Joel Soete wrote:
>> Finaly this trial version of function:
>>
>>
>> BOOLEAN isa_null_partition_record(struct partition *p)
>> {
>>       if (p->boot_ind == 0x00 &&
>>           p->head == 0x00 &&
>>           p->sector == 0x00 &&
>>           p->cyl == 0x00 &&
>>           p->sys_ind == 0x00 &&
>>           p->end_head == 0x00 &&
>>           p->end_sector == 0x00 &&
>>           p->end_cyl == 0x00 &&
>>           p->start_sect == 0x00 &&
>>           p->nr_sects == 0x00 )
>>           return TRUE;
>
>Since start_sect and nr_sects are ints, this code will also generate an
>"unaligned data reference fault" like the original code did.

Trust me it does not? (it works fine)

>You need
>to find the origin of "struct partition *p" when the address is un-aligned.
>
Very hard to define:
a. the previous code works (again all odds)
b. the following trial code:
"
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

typedef u_int8_t  BOOLEAN;

#ifndef TRUE
  #define TRUE  1
#endif
#ifndef FALSE
  #define FALSE 0
#endif

struct partition {
    unsigned char boot_ind;     /* 0x80 - active */
    unsigned char head;     /* starting head */
    unsigned char sector;       /* starting sector */
    unsigned char cyl;      /* starting cylinder */
    unsigned char sys_ind;      /* What partition type */
    unsigned char end_head;     /* end head */
    unsigned char end_sector;   /* end sector */
    unsigned char end_cyl;      /* end cylinder */
    unsigned int start_sect;    /* starting sector counting from 0 */
    unsigned int nr_sects;      /* nr of sectors in partition */
};

BOOLEAN isa_null_partition_record(struct partition *p)
{
    int          i;
    u_int32_t   *uip = (u_int32_t *) p;

    for (i=0; i<4; i++) {
        if (*uip!=0x00) return FALSE;
    }

    return TRUE;
}

int main(int argc, char * * argv, char * * env) {

    struct partition p1, p2;

    p1.boot_ind=0;
    p1.head=0;
    p1.sector=0;
    p1.cyl=0;
    p1.sys_ind=0;
    p1.end_head=0;
    p1.end_sector=0;
    p1.end_cyl=0;
    p1.start_sect=0;
    p1.nr_sects=0;

    printf("Is that p1 is a null partition: %u\n", isa_null_partition_record(&p1));

    p2.boot_ind=1;
    p2.head=2;
    p2.sector=3;
    p2.cyl=4;
    p2.sys_ind=5;
    p2.end_head=6;
    p2.end_sector=7;
    p2.end_cyl=8;
    p2.start_sect=9;
    p2.nr_sects=10;

    printf("Is that p2 is a null partition: %u\n", isa_null_partition_record(&p2));
    return 0;
}
"
did not reproduce the problem.


Even if in the previous code, I replace:
BOOLEAN isa_null_partition_record(struct partition *p)
{
    int          i;
    u_int32_t   *uip = (u_int32_t *) p;

    for (i=0; i<4; i++) {
        if (*uip!=0x00) return FALSE;
    }

    return TRUE;
}
by
extern BOOLEAN isa_null_partition_record(struct partition *p);

and also link it with the original library containing isa_null_partition_record,
I can no more reproduce the problem.

The only difference I can notice is that 'isa_null_partition_record' is
not directly used by evms tools but through modules loaded at run time (the
cause of gdb debug difficulties) (or am I wrong and a subtil detail escape
to my attention)?

What can I do to analyse this problem? (printing all p addresses and its
elements
during a run with the original code and compare with a run with modified
code?)

Thanks again for attention and help,
    Joel

Re: [parisc-linux] Back to evms-1.0.1 && unaligne access && gdb

[Grant Grundler]

jsoe0708@tiscali.be wrote:
> >Since start_sect and nr_sects are ints, this code will also generate an
> >"unaligned data reference fault" like the original code did.
> 
> Trust me it does not? (it works fine)

then I'll wager there is padding between the char and int fields
of that struct.

> >You need
> >to find the origin of "struct partition *p" when the address is un-aligned.
> >
> Very hard to define:
> a. the previous code works (again all odds)
> b. the following trial code:
...

> int main(int argc, char * * argv, char * * env) {
> 
>     struct partition p1, p2;

...
> did not reproduce the problem.

Things on the stack (local var) are properly aligned.
Malloc a block of mem and then point to an unaligned address
in that block.

> What can I do to analyse this problem? (printing all p addresses and its
> elements
> during a run with the original code and compare with a run with modified
> code?)

yes. You want to verify the addreses are unaligned.

grant

[parisc-linux] Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[jsoe0708]

Hello Grant,

>
>then I'll wager there is padding between the char and int fields
>of that struct.

That is also what I believe to understand.

>
...
>> What can I do to analyse this problem? (printing all p addresses and its
>> elements
>> during a run with the original code and compare with a run with modified
>> code?)
>
>yes. You want to verify the addreses are unaligned.

And here is some data of my analyse:

First surprise in the two case (original checks.c and my checks.c with only
"if (p->boot_ind != 0x00 && ") p addresses are exactly the same here is an
example:
with checks.c.orig:
dmesg
...
evms_vgscan(10137): unaligned access to 0x000272ee at ip=0x4020a2ab

corresponding adresses:
p            add: 0x272ee
p.boot_ind   add: 0x272ee
p.head       add: 0x272ef
p.sector     add: 0x272f0
p.cyl        add: 0x272f1
p.sys_ind    add: 0x272f2
p.end_head   add: 0x272f3
p.end_sector add: 0x272f4
p.end_cyl    add: 0x272f5
p.start_sect add: 0x272f6
p.nr_sects   add: 0x272fa

with the checks.c.new:
p            add: 0x272ee
p.boot_ind   add: 0x272ee
p.head       add: 0x272ef
p.sector     add: 0x272f0
p.cyl        add: 0x272f1
p.sys_ind    add: 0x272f2
p.end_head   add: 0x272f3
p.end_sector add: 0x272f4
p.end_cyl    add: 0x272f5
p.start_sect add: 0x272f6
p.nr_sects   add: 0x272fa

What do you think?

Thanks again for attention and help,
    Joel

PS1: just in case I made error here is the code I add to print addresses:
    printf("p            add: %p\n", p);
    printf("p.boot_ind   add: %p\n", &(p->boot_ind));
    printf("p.head       add: %p\n", &(p->head));
    printf("p.sector     add: %p\n", &(p->sector));
    printf("p.cyl        add: %p\n", &(p->cyl));
    printf("p.sys_ind    add: %p\n", &(p->sys_ind));
    printf("p.end_head   add: %p\n", &(p->end_head));
    printf("p.end_sector add: %p\n", &(p->end_sector));
    printf("p.end_cyl    add: %p\n", &(p->end_cyl));
    printf("p.start_sect add: %p\n", &(p->start_sect));
    printf("p.nr_sects   add: %p\n", &(p->nr_sects));

PS2: If you think it could help you more, I can send you the complete logs
I get from the two runs as well as sources

[parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[Grant Grundler]

jsoe0708@tiscali.be wrote:
...
> And here is some data of my analyse:
> 
> First surprise in the two case (original checks.c and my checks.c with only
> "if (p->boot_ind != 0x00 && ") p addresses are exactly the same here is an
> example:

...
> with the checks.c.new:
> p            add: 0x272ee
> p.boot_ind   add: 0x272ee
> p.head       add: 0x272ef
> p.sector     add: 0x272f0
> p.cyl        add: 0x272f1
> p.sys_ind    add: 0x272f2
> p.end_head   add: 0x272f3
> p.end_sector add: 0x272f4
> p.end_cyl    add: 0x272f5
> p.start_sect add: 0x272f6
> p.nr_sects   add: 0x272fa
> 
> What do you think?

checks.c.new will generate a "misaligned access" when "p.start_sect"
is accessed. 0x272f6 is aligned on 2byte address, not 4 byte.
Ditto for "p.nr_sects".

You sure checks.c.new is referencing 0x272f6 and not something else?
You reviewed dmesg output?

...
> PS1: just in case I made error here is the code I add to print addresses:

printf's look right.

> PS2: If you think it could help you more, I can send you the complete logs
> I get from the two runs as well as sources

thanks but no. I'm just trying to help you understand "unaligned access".

grant

[parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[John David Anglin]

> >then I'll wager there is padding between the char and int fields
> >of that struct.
> 
> That is also what I believe to understand.

Unlikely.  The unaligned trap handler in the kernel is probably
fixing the unaligned access.  You need to look in the kernel log
to see if this is happening.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

[parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[jsoe0708]

Dave,
>
>
>> >then I'll wager there is padding between the char and int fields
>> >of that struct.
>> 
>> That is also what I believe to understand.
>
>Unlikely.  The unaligned trap handler in the kernel is probably
>fixing the unaligned access.  You need to look in the kernel log
>to see if this is happening.
>
Nothing to notice about unalign access kernel trap in any /var/log files
(with checks.c.new) Is there some "debug" #define to set to increase verbosity
of this trap?

Thanks a lot,
    Joel

[parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[jsoe0708]

>jsoe0708@tiscali.be wrote:
>...
>> And here is some data of my analyse:
>> 
>> First surprise in the two case (original checks.c and my checks.c with
>only
>> "if (p->boot_ind != 0x00 && ") p addresses are exactly the same here is
>an
>> example:
>
>...
>> with the checks.c.new:
>> p            add: 0x272ee
>> p.boot_ind   add: 0x272ee
>> p.head       add: 0x272ef
>> p.sector     add: 0x272f0
>> p.cyl        add: 0x272f1
>> p.sys_ind    add: 0x272f2
>> p.end_head   add: 0x272f3
>> p.end_sector add: 0x272f4
>> p.end_cyl    add: 0x272f5
>> p.start_sect add: 0x272f6
>> p.nr_sects   add: 0x272fa
>> 
>> What do you think?
>
>checks.c.new will generate a "misaligned access" when "p.start_sect"
>is accessed. 0x272f6 is aligned on 2byte address, not 4 byte.
>Ditto for "p.nr_sects".
>
(now I have understand, well I think :) )

>You sure checks.c.new is referencing 0x272f6 and not something else?

For this I will have to find all call to this function and write p.start_sect
address and content before.

(very tricky problem to surround isn'it ;<) )

>You reviewed dmesg output?

Yes (I have a mincom 'screen' on this system console and I also examine kern.log
as recall Dave)


Many thanks,
    Joel

PS: In the mean time I learn that this bug was already fix by:
BOOLEAN isa_null_partition_record(struct partition *p)
{
    int          i;
    u_int8_t    *uip = (u_int8_t *) p;
    int          psize = sizeof(struct partition);

    for (i=0; i<psize; i++) {
        if (*(uip+i) != 0x00) return FALSE;
    }

    return TRUE;
}

but not yet comited :?

[parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[jsoe0708]

>>jsoe0708@tiscali.be wrote:
>>...
>>> And here is some data of my analyse:
>>> 
>>> First surprise in the two case (original checks.c and my checks.c with
>>only
>>> "if (p->boot_ind != 0x00 && ") p addresses are exactly the same here
is
>>an
>>> example:
>>
>>...
>>> with the checks.c.new:
...
>>
>>checks.c.new will generate a "misaligned access" when "p.start_sect"
>>is accessed. 0x272f6 is aligned on 2byte address, not 4 byte.
>>Ditto for "p.nr_sects".
>>
>(now I have understand, well I think :) )
>
>>You sure checks.c.new is referencing 0x272f6 and not something else?
>
>For this I will have to find all call to this function and write p.start_sect
>address and content before.
>
>(very tricky problem to surround isn'it ;<) )
>
And so here is a test (where an unaligne access did not occurs where it would??):
(isa_valid_partition_record) file checks.c
### before the call ###
part.start_sect add: 0x242a6
part.start_sect    : 9439488   [1]
part.nr_sects   add: 0x242aa
part.nr_sects      : 15791872  [2]
### Into the function isa_null_partition_record() ###
p            add: 0x2429e
p.boot_ind   add: 0x2429e
p.head       add: 0x2429f
p.sector     add: 0x242a0
p.cyl        add: 0x242a1
p.sys_ind    add: 0x242a2
p.end_head   add: 0x242a3
p.end_sector add: 0x242a4
p.end_cyl    add: 0x242a5
p.start_sect add: 0x242a6
p.start_sect    : 9439488      [3]
p.nr_sects   add: 0x242aa
p.nr_sects      : 15791872     [4]

As far as I can see [1] and [3] (as well as [2] and [4]) seems to show that
it point actualy to the same thing.

And here is an other sample:

(isa_valid_partition_record) file checks.c
part.start_sect add: 0x24556
part.start_sect    : 536870912
part.nr_sects   add: 0x2455a
part.nr_sects      : 3768004864
p            add: 0x2454e
p.boot_ind   add: 0x2454e
p.head       add: 0x2454f
p.sector     add: 0x24550
p.cyl        add: 0x24551
p.sys_ind    add: 0x24552
p.end_head   add: 0x24553
p.end_sector add: 0x24554
p.end_cyl    add: 0x24555
p.start_sect add: 0x24556
p.start_sect    : 536870912
p.nr_sects   add: 0x2455a
p.nr_sects      : 3768004864
p            add: 0x2454e
p.boot_ind   add: 0x2454e
p.head       add: 0x2454f
p.sector     add: 0x24550
p.cyl        add: 0x24551
p.sys_ind    add: 0x24552
p.end_head   add: 0x24553
p.end_sector add: 0x24554
p.end_cyl    add: 0x24555
p.start_sect add: 0x24556
p.start_sect    : 536870912
p.nr_sects   add: 0x2455a
p.nr_sects      : 3768004864

Joel



Big Brother Anders  - With Tiscali you will see it all !  Check it up on
 www.tiscali.be/bigbrother

Re: [parisc-linux] Re: Unaligne access [was: Back to evms-1.0.1 && unaligne access && gdb ]

[Randolph Chung]

> >Unlikely.  The unaligned trap handler in the kernel is probably
> >fixing the unaligned access.  You need to look in the kernel log
> >to see if this is happening.
> >
> Nothing to notice about unalign access kernel trap in any /var/log files
> (with checks.c.new) Is there some "debug" #define to set to increase verbosity
> of this trap?

no, it will log by default.. nothing to configure.

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/