On Thu, Oct 22, 2015 at 7:52 AM, Julian Seward <jsew...@acm.org> wrote:
>
>> When PIC is in effect, the Global Offset Table (GOT) is utilized.
>> Under the Linux ABI, that means EBX/RBX must be preserved because it
>> holds the pointer to the GOT.
>
> If the GOT pointer register is getting trashed by inline assembly, I'd
> imagine your program would crash very shortly afterwards, in a somewhat
> obvious way (if you're proficient at reading assembly that is).
Yeah, that's what I hoped for. But its showing up as a hang at the
moment. (And I would probably suffer my fair share of reading the
ASM).
No one has provided me with a dump, and no one has provided me with
remote/SSH access to a misbehaving machine. They are not making it
easy :(
I'm trying to go the extra mile because this could be a portent of
things to come at GCC 5.2 or 5.3. I want to get out ahead of this
issue in case it becomes wider spread.
> Also, if the inline asm is wrong, different optimisation levels may well
> have different effects. Is it -O level dependent?
The issue does not appear to be transient based on optimizations. The
folks who are reporting it use -O{1|2|3}.
I know a -DDISABLE_ASM resolves the issue. I don't know what happens
under the configuration {no-PIC, with-ASM}. No one has reported back.
I also know -mno-sse{3|4|4_1|4_2} does not affect the issue.
> You list a bunch of memory-error checking tools (Memcheck, ASan, etc) but
> don't say anything about race-checking (Helgrind, DRD, TSan, etc). Did you
> check for races and other threading problems?
The self tests are single threaded, so I guess I am fortunate that its
not a factor. Thank the {Lord|Allay|<Favorite Deity>} for small
miracles :)
Jeff
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
