[Linux-Xtensa] Re: sched_clock always 0 and no process time accounting with 3.11-rc1

Chris Zankel chris at zankel.net
Wed Jul 17 00:52:34 PDT 2013


HI Baruch,

It's actually a problem in binutils, and I haven't checked if a fix has
been included recently.

What happens is that negative offsets become huge values on 64-bit
hosts, so the emitted relocation entry has a large positive offset
instead of negative offset. I saw this problem with glibc's  vfprintf

BTW, do you have write access to the Wiki?

Thanks,
-Chris


This was my original analysis. Reading it again, I'm not sure if I still understand what I wrote ;-)



Turned out that the code
doesn't support 'negative' diffs. This exacerbates for 64-bit hosts (but
I think it also exists on 32-bit hosts for DIFF8 and DIFF16). Diffs are
'unsigned' so calculated offsets become larger(!) instead of smaller.

The code in question first calculates the original end address (=
original start address + diff) before applying relaxation, and then
determines the new start address and difference from the new start and
end address after subtracting relaxation bytes for each:

new_end_offset = offset_with_removed_text
(&target_relax_info->action_list, r_rel.target_offset + diff_value);
diff_value = new_end_offset - new_reloc.target_offset;

The function offset_with_removed_text adds relaxation bytes as long as
this condition is met:

if (r->offset > offset)
  break;
...
removed += r->removed_bytes;

For example, with an address of 0x100 and an 8-bit diff of 0xf0, the
address that's checked in the function offset_with_removed_text()
becomes 0x1f0 (instead of 0x10), so the loop goes way beyond 0x10 and
adds additional 'removed_bytes'.


On 07/17/2013 12:14 AM, Baruch Siach wrote:
> Hi Chris,
>
> On Wed, Jul 17, 2013 at 12:02:10AM -0700, Chris Zankel wrote:
>> On 07/16/2013 11:47 PM, Baruch Siach wrote:
>>>> According to C99 the behaviour of (1 << 32) is undefined on platforms with
>>>> 32 bit int, so it could yield any value.
>>> But so is ARM, isn't it?
>> The handling of constants might be target-architecture dependent.
>>
>> On a somewhat related issue, are you using a 32-bit host or 64-bit host?
>> Note that 64-bit cross compilation is known to be broken for Xtensa, I
>> had a problem running glibc when compiled with cross compiler on a
>> 64-bit host.
> Yes, my host is x86_64. I haven't encountered any problem yet. But thanks for 
> the warning, I'll keep that in mind. I think it's worth a mention in the 
> linux-xtensa wiki. It surly worth a fix as well, I guess. Are there any 
> samples of code that are known to be break with 64 bit host?
>
> baruch
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: elf32-xtensa.c.patch
Type: text/x-patch
Size: 1491 bytes
Desc: not available
Url : http://lists.linux-xtensa.org/pipermail/linux-xtensa/attachments/20130717/f649fe3d/elf32-xtensa.c.bin


More information about the linux-xtensa mailing list