[parisc-linux] More unaligned references

[parisc-linux] More unaligned references

[Matthew Wilcox]

This is in apache-ssl.

$ gdb ./apache 
This GDB was configured as "hppa2.0-unknown-linux-gnu"...
(gdb) run
Starting program: /home/willy/test/apache-ssl-1.3.19.1+1.42/build-tree/apache_1.3.19/src/./apache 

Program received signal SIGBUS, Bus error.
0x00020224 in Letext ()
(gdb) bt
#0  0x00020224 in Letext ()
#1  0x0001cf40 in create_server_config (p=0x85040, s=0x85068)
    at http_config.c:186
#2  0x0001f444 in init_server_config (p=0x85040) at http_config.c:1625
#3  0x0001f518 in ap_read_config (p=0x85040, ptemp=0x89080, 
    confname=0x7c97c "/etc/apache-ssl/httpd.conf") at http_config.c:1657
#4  0x00029be0 in main (argc=1, argv=0x7ff00258) at http_main.c:5114

(gdb) x/12i $pc-20
0x20210 <Letext+1552>:  addil 4800,dp,%r1
0x20214 <Letext+1556>:  ldw 154(sr0,r1),r21
0x20218 <Letext+1560>:  bv r0(r21)
0x2021c <Letext+1564>:  ldw 158(sr0,r1),r19
0x20220 <Letext+1568>:  addil 4800,dp,%r1
0x20224 <Letext+1572>:  ldw fb(sr0,r1),r21
0x20228 <Letext+1576>:  bv r0(r21)
0x2022c <Letext+1580>:  ldw ff(sr0,r1),r19
0x20230 <Letext+1584>:  addil 4800,dp,%r1
0x20234 <Letext+1588>:  ldw 21c(sr0,r1),r21
0x20238 <Letext+1592>:  bv r0(r21)
0x2023c <Letext+1596>:  ldw 220(sr0,r1),r19

so we seem to be in the middle of a jump table here.

init_server_config looks like this, btw:

static void *create_server_config(pool *p, server_rec *s)
{
    void **conf_vector = (void **) ap_pcalloc(p, sizeof(void *) * (total_modules
 + DYNAMIC_MODULE_LIMIT));
    module *modp;

    for (modp = top_module; modp; modp = modp->next) {
        if (modp->create_server_config)
            conf_vector[modp->module_index] = (*modp->create_server_config) (p, 
s);
    }

    return (void *) conf_vector;
}

Which fits the jump table explanation.  So something's getting trashed
and I really don't know where.  This is with matt's newcompilers-20010520
debs; binutils 2.11.90.0.8 plus modra's patch, gcc 3.0.ds5-0pre010427
with an hppa patch and glibc 2.2.3-2 with an hppa patch.  fwiw, the same
problem happened with binutils 2.11.90.0.1 from the baseplus-0404 tarball.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] More unaligned references

[Paul Bame]

> 0x20220 <Letext+1568>:  addil 4800,dp,%r1
> 0x20224 <Letext+1572>:  ldw fb(sr0,r1),r21
> 0x20228 <Letext+1576>:  bv r0(r21)

FYI in case others run across it, this was discovered to be the ".plt-1" bug.
To find out, use 'objdump -h' to figure out where .plt is loaded.  Then add
0x4800 plus 0xfb plus the dp register (r27).  If that's .plt-1 you've found
the bug which is/should-be squashed in recent bits.

	-P

Re: [parisc-linux] More unaligned references

[Matthew Wilcox]

On Mon, May 21, 2001 at 04:27:07PM -0600, Paul Bame wrote:
> FYI in case others run across it, this was discovered to be the ".plt-1" bug.
> To find out, use 'objdump -h' to figure out where .plt is loaded.  Then add
> 0x4800 plus 0xfb plus the dp register (r27).  If that's .plt-1 you've found
> the bug which is/should-be squashed in recent bits.

Not convinced.  Yes, this is in fact .plt-1.  However, that bug is
supposed to be both fixed in this version of binutils and an assert
added to catch it happening.  However, no assert is being tripped.
FWIW, the offending caller is:

     1d0:       eb e0 00 00     b,l 1d8 <create_server_config+0x5c>,r31
                        1d0: R_PARISC_PCREL17F  $$dyncall


-- 
Revolutions do not require corporate support.

Re: [parisc-linux] More unaligned references

[amodra]

On Mon, May 21, 2001 at 11:40:50PM +0100, Matthew Wilcox wrote:
> On Mon, May 21, 2001 at 04:27:07PM -0600, Paul Bame wrote:
> > FYI in case others run across it, this was discovered to be the ".plt-1" bug.
> > To find out, use 'objdump -h' to figure out where .plt is loaded.  Then add
> > 0x4800 plus 0xfb plus the dp register (r27).  If that's .plt-1 you've found
> > the bug which is/should-be squashed in recent bits.
> 
> Not convinced.  Yes, this is in fact .plt-1.  However, that bug is
> supposed to be both fixed in this version of binutils and an assert
> added to catch it happening.  However, no assert is being tripped.
> FWIW, the offending caller is:
> 
>      1d0:       eb e0 00 00     b,l 1d8 <create_server_config+0x5c>,r31
>                         1d0: R_PARISC_PCREL17F  $$dyncall

A shared library created with the "bad" binutils exports millicode syms it
isn't supposed to, which the linker later rejects, resulting in .plt-1
references.  The assert should still have triggered...

A quick check whether a library is good is:
nm --dynamic <lib> | grep '\$\$'

This will show exported millicode syms since they start with '$$'.

Alan