Re: ELF segment based qOffsets

Hello all,

We've ran into the following problem while running the ppc
cross-gdb
with the U-Boot firmware image:

bash# ./gdb u-boot
GNU gdb Red Hat Linux (6.7-1rh)
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/l
icenses/gpl.html>
This is free software: you are free to change and
redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type
"show 
copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu
--target=ppc-linux".
The target architecture is set automatically (currently
powerpc:403)
..

warning: Loadable segment ".resetvec" outside of
ELF segments

warning: Loadable segment ".bootpg" outside of ELF
segments
(gdb)


bash# readelf -lS u-boot
There are 27 section headers, starting at offset 0xc3dc0:

Section Headers:
   [Nr] Name              Type            Addr     Off   
Size   ES 
Flg Lk Inf Al
   [ 0]                   NULL            00000000 000000
000000 00 
     0   0  0
   [ 1] .resetvec         PROGBITS        fffffffc 02e208
000004 00 
AX  0   0  1
   [ 2] .bootpg           PROGBITS        fffff000 02d20c
00033c 00 
AX  0   0  1
   [ 3] .text             PROGBITS        fffc0000 0000a0
022f9c 00 
AX  0   0 16
   [ 4] .rodata           PROGBITS        fffe2f9c 02303c
007250 00 
  A  0   0  4
   [ 5] .reloc            PROGBITS        fffea200 02a2a0
001204 00 
WA  0   0  1
...
Program Headers:
   Type           Offset   VirtAddr   PhysAddr   FileSiz
MemSiz  Flg 
Align
   LOAD           0x0000a0 0xfffc0000 0xfffc0000 0x2d16c
0x35cd0 RWE 0x10
   LOAD           0x02d20c 0xfffff000 0xfffff000 0x01000
0x01000 R E 0x1
   GNU_STACK      0x000000 0x00000000 0x00000000 0x00000
0x00000 RWE 0x4

  Section to Segment mapping:
   Segment Sections...
    00     .text .rodata .reloc .data .data.rel.local 
.data.rel.ro.local .data.rel data .u_boot_cmd
    01     .resetvec .bootpg
    02


You see, the warnings are caused by the fact that the
segment 01 has
address/size values which wraps to 0 in the following 'if'
condition
introduced by the $subj in elfread.c,
elf_symfile_segments():
...
&& vma < segments[j]->p_vaddr +
segments[j]->p_memsz)


The place above is trivial to fix, but I wonder will be any
other consequences to the remote debugging of such kind of
images? (I can't try this at the moment)

Regards,
Sergei

On Fri, Dec 14, 2007 at 01:27:33PM +0300, Sergei Poselenov
wrote:
> You see, the warnings are caused by the fact that the
segment 01 has
> address/size values which wraps to 0 in the following
'if' condition
> introduced by the $subj in elfread.c,
elf_symfile_segments():
> ...
> && vma < segments[j]->p_vaddr +
segments[j]->p_memsz)

Drat.  Yes, this just seems like a bug.  I'll try to fix it
later.

> The place above is trivial to fix, but I wonder will be
any
> other consequences to the remote debugging of such kind
of
> images? (I can't try this at the moment)

I don't think there should be any problems.  There would be
a little
trouble debugging code from those sections if the image was
relocated
(qOffsets response), but yours shouldn't be; it goes at the
address in
the ELF file.

-- 
Daniel Jacobowitz
CodeSourcery

Hello Daniel,

Daniel Jacobowitz wrote:
> On Fri, Dec 14, 2007 at 01:27:33PM +0300, Sergei
Poselenov wrote:
>> You see, the warnings are caused by the fact that
the segment 01 has
>> address/size values which wraps to 0 in the
following 'if' condition
>> introduced by the $subj in elfread.c,
elf_symfile_segments():
>> ...
>> && vma < segments[j]->p_vaddr +
segments[j]->p_memsz)
> 
> Drat.  Yes, this just seems like a bug.  I'll try to
fix it later.
> 

Please review attached.

>> The place above is trivial to fix, but I wonder
will be any
>> other consequences to the remote debugging of such
kind of
>> images? (I can't try this at the moment)
> 
> I don't think there should be any problems.  There
would be a little
> trouble debugging code from those sections if the image
was relocated
> (qOffsets response), but yours shouldn't be; it goes at
the address in
> the ELF file.
> 
OK, thanks.

Regards,
Sergei

Hello again,

Sorry, previous patch is wrong, please ignore.
Attached is the correct one.

Regards,
Sergei

Sergei Poselenov wrote:
> Hello Daniel,
> 
> Daniel Jacobowitz wrote:
>> On Fri, Dec 14, 2007 at 01:27:33PM +0300, Sergei
Poselenov wrote:
>>> You see, the warnings are caused by the fact
that the segment 01 has
>>> address/size values which wraps to 0 in the
following 'if' condition
>>> introduced by the $subj in elfread.c,
elf_symfile_segments():
>>> ...
>>> && vma < segments[j]->p_vaddr +
segments[j]->p_memsz)
>>
>> Drat.  Yes, this just seems like a bug.  I'll try
to fix it later.
>>
> 
> Please review attached.
> 
>>> The place above is trivial to fix, but I wonder
will be any
>>> other consequences to the remote debugging of
such kind of
>>> images? (I can't try this at the moment)
>>
>> I don't think there should be any problems.  There
would be a little
>> trouble debugging code from those sections if the
image was relocated
>> (qOffsets response), but yours shouldn't be; it
goes at the address in
>> the ELF file.
>>
> OK, thanks.
> 
> Regards,
> Sergei
> 
> 
>
------------------------------------------------------------
------------
> 
> --- gdb-6.7/gdb/elfread.c.orig	2007-12-19
16:27:32.000000000 +0100
> +++ gdb-6.7/gdb/elfread.c	2007-12-19 16:32:21.000000000
+0100
>  -107,7 +107,7  elf_symfile_segments (bfd *abfd)
>        for (j = 0; j < num_segments; j++)
>  	if (segments[j]->p_memsz > 0
>  	    && vma >= segments[j]->p_vaddr
> -	    && vma < segments[j]->p_vaddr +
segments[j]->p_memsz)
> +	    && (vma - segments[j]->p_vaddr) >
segments[j]->p_memsz)
>  	  {
>  	    data->segment_info[i] = j + 1;
>  	    break;