<zmike>
gdb attach, source WineReload.py, wr, now you can use gdb
<karolherbst>
it doesn't work
<zmike>
Kayden: ^
<zmike>
karolherbst: you're on your own
<zmike>
🙏
<Kayden>
huh, neat
camus has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
<DemiMarie>
Anyone here familiar with AMD GPU command processing?
columbarius has joined #dri-devel
<karolherbst>
zmike: yeah apparently. All I can tell is that even with that, nothing gets resolved and the restarting the process within gdb issue isn't fixed by it either.
<zmike>
the script is for debugging steam games, so probably you have to tweak it for general use
<zmike>
assuming you don't already have symbols loaded
co1umbarius has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah well... I don't understand why wine can't just provide a debugging thing which works instead
<DemiMarie>
File a bug in Wine
<karolherbst>
that's going to be a fun one
<zmike>
eh it does work, just not for your purpose
<karolherbst>
debugging linux libs? I guess not
<zmike>
that's what regular gdb attach is for
<HdkR>
Restarting the process under gdb doesn't usually work because it's usually a child process spinning off some temporary thing anyway
<karolherbst>
ehh apparently winedbg isn't able to parse my debug info anyway.. *sigh*
<karolherbst>
yeah.. it's all very cursed
<HdkR>
Was debugging an application a few days ago and I could only gdb attach the very final process once I saw it had crashed and spinning in a crash loop
<karolherbst>
heh
<HdkR>
no amount of child execve and fork option setting would give it to me directly
heat has quit [Remote host closed the connection]
<karolherbst>
what process did you attach to? the exe one?
heat has joined #dri-devel
<HdkR>
It did end up eventually being an exe process. The parent one basically did nothing while waiting for the child one to get done
<HdkR>
But it also did some wacky reparenting which is why gdb couldn't track it
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
jkrzyszt has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<DemiMarie>
Can gdb be set to track all child processes?
<karolherbst>
well.. define "all"
<karolherbst>
it can follow children
<karolherbst>
but then it detaches from the old parent
<karolherbst>
so if the parent spawns multiple children you end up with the first one
<DemiMarie>
That’s just a gdb limitation then. A debugger that could trace multiple children at once would not have that problem.
<karolherbst>
well, true
<karolherbst>
do you know such a debugger?
<DemiMarie>
You can also break on return from clone() and attach manually.
<karolherbst>
mhh.. fair point actually
<jenatali>
WinDbg
<jenatali>
:P
<karolherbst>
heh
<karolherbst>
I think I'll just use printf to debug this...
<DemiMarie>
I don’t know such a debugger, but one can be emulated.
<DemiMarie>
Might be something worth implementing and upstreaming to GDB or LLDB.
<karolherbst>
yeah... though I suspect this might require rewriting most of the core bits
<jenatali>
Not that it's useful for you, but yeah WinDbg can trace multiple child processes and switch between them, and set breaks in any of them
<jenatali>
Comes in handy
<karolherbst>
power feature for power users
<DemiMarie>
karolherbst: LLDB might be easier to implement this in.
<karolherbst>
probably
<DemiMarie>
For one LLDB is actually a library.
<karolherbst>
okay.. getting close
angular_mike______ has quit [Read error: Connection timed out]
angular_mike______ has joined #dri-devel
<karolherbst>
I do have some types around with explicit_stride set to 0 indeed.. and that messes up array types
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<jenatali>
karolherbst: Do you have a valid sizing callback passed when setting up explicit types?
<karolherbst>
yeah
<karolherbst>
using glsl_get_cl_type_size_align
<karolherbst>
uhhhh
<karolherbst>
I'm reading the CL code
<karolherbst>
and it's...
<karolherbst>
uhhhh
<karolherbst>
I think mesa is wrong here anyway
<karolherbst>
or maybe the spir-v...
<karolherbst>
would have to double check
<karolherbst>
((__local int*)&task)[tid] = ((__global int*)(&tasks[get_group_id(0) * tasksPerChannel].data))[tid]; is the code
<karolherbst>
but the chains is /* &(*(struct.FLACCLSubframeTask *)ssa_1)[ssa_24].field0.field0[ssa_18] */
<karolherbst>
why is there .field0.field0?
<karolherbst>
why is compute code always looking so weirdly cursed
<karolherbst>
oh well.. it's 4 am now :) I'll figure out the rest tomorrow
<jenatali>
Seems it's being too aggressive at removing the cast where the casted-to type is the same as the casted-from type
<jenatali>
But the from type doesn't have stride
<karolherbst>
yeah
<karolherbst>
something soemthing
<karolherbst>
I'm sure I'll find the spot tomorrow
<karolherbst>
and I probably also add support for this kind of debugging to rusticl, because it's getting annoying :D
<jenatali>
Seems like something gfxstrand would want to look at. I hit similar loss-of-info problems with cast deref opts
<jenatali>
Mine was alignment rather than stride though
<karolherbst>
I think I'll do dark magic macro stuff for the passes: pass!(nir.nir_opt_deref()); and pass!(nir.nir_shader_gather_info(nir.entrypoint());...or something.. could be fun once I figure out how I want it to look like
liyi__ has joined #dri-devel
jdavies has joined #dri-devel
jdavies_ has quit [Remote host closed the connection]
jdavies is now known as Guest5359
<DavidHeidelberg[m]>
robclark: Hey! Any chance we could get CI `http://10.42.0.1:8888/` as `caching-proxy` on default port 80? I'm trying to combine our LAVA cache (using default) with the google a630 and if this change would be easily doable on your side it would simplify setup a bit
heat_ has quit [Ping timeout: 480 seconds]
liyi_ has joined #dri-devel
dviola has quit [Quit: WeeChat 3.7.1]
Zopolis4 has joined #dri-devel
liyi__ has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem1 has joined #dri-devel
bmodem has quit [Read error: Connection reset by peer]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
alain has left #dri-devel [#dri-devel]
alain has joined #dri-devel
<karolherbst>
*increased
<karolherbst>
and anyway, if somebody minds acking/reviewing the llvmpipe ci patch I can probably land it
alain has quit []
alain has joined #dri-devel
agd5f_ has quit []
agd5f has joined #dri-devel
alain has left #dri-devel [#dri-devel]
swisstackle has joined #dri-devel
illwieckz has joined #dri-devel
smiles has quit [Ping timeout: 480 seconds]
<swisstackle>
Whatsup guys. I am Alain, a recent CS graduate and former student athlete. I am currently making an effort to learn OS (Unix) dev and possibly contribute to the Linux Kernel soon (Currently selfstudying with this course: https://ocw.mit.edu/courses/6-828-operating-system-engineering-fall-2012/pages/syllabus/). I am also try to get my skills up to the point where I'll be able to participate in an X.org EVoC.
bgs has joined #dri-devel
<javierm>
tzimmermann: sorry, I was on PTO today. Sure, I'll do it tomorrow morning
<tzimmermann>
thanks a lot
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<karolherbst>
I'm quite confident from a "does it cause regression" pov I think, but I'm wondering if the series is simply "too big" for backporting... dunno
Ahuj has quit []
<karolherbst>
ohh wait.. 22.2 is EoL. right?
<karolherbst>
nvm then
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
idr has joined #dri-devel
<karolherbst>
and I think I'll be starting to mess with "rustc --cfg"
gouchi has joined #dri-devel
heat_ has quit [Remote host closed the connection]