Open g2flyer opened 2 months ago
BTW: Unless somebody knows right away what the issue is, this is probably not worth spending time investigating. Makes me wonder, though, should i maybe create a small PR to update the documentation with a corresponding comment?
I'm pretty sure it worked correctly in the past, it's quite unlucky that this scenario wasn't tested. Instead of documenting this, I'd rather find someone to debug and fix it, as it's clearly a bug :)
From a quick bisect, it looks like https://github.com/gramineproject/gramine/pull/1820/commits/72668bb391d9a311148d8e824fb006f314e8dbba introduced some regressions.
From a quick bisect, it looks like 72668bb introduced some regressions.
After a quick check, I don't see anything suspicious... Clearly the problem is somewhere around here: https://github.com/gramineproject/gramine/blob/ca534cea27bff7a13e2127c8db0b77e676f6b7de/pal/src/pal_rtld.c#L717
But I don't see how that particular commit could modify anything... Needs proper debugging.
Description of the problem
While standard software breakpoints (
break
) work for PAL and application, it seems currently for libos one needs hardware breakpoints (hbreak
) to interrupt the program (setting breakpoints for libos functions withbreak
seems to work but the program never stops ...). I think this previously did work withbreak
also for libos but i'm not 100% sure and, more importantly, i don't know when it stopped working. Usinghbreak
instead ofbreak
is not a big deal, but thought i would create this issue so folks could find this workaround while searching issues if they run in the same problem ...PS: Note that CI does test gdb break points but only for PAL (which works), not libos (which doesn't) ....
Steps to reproduce
GDB=1 gramine-direct ...
b ipf_open
run
Expected results
gdb should stop when
ipf_open
is encounteredActual results
gdb runs to the end (even though, with
log_level=trace
one can see thatipf_open
was calledGramine commit hash
68b9602aeece219cca617e18f26306f6af9f6049