<shachaf>
rr apparently has a ptrace emulation feature that lets it trace a program that uses ptrace, by emulating its ptrace calls.
<shachaf>
(Since a program can only have one tracer.)
<andrewrk>
computing at its finest
<andrewrk>
??? readelf: Warning: file index 0 > number of files 1
<andrewrk>
last I checked 0 < 1
<mikdusan>
https://github.com/gimli-rs/gimli has some example programs .debug_info parser and dwarf-validate. maybe if those are easy to build, they could give a decent hint
<andrewrk>
good thinking
<ronsor>
is it possible to async call a function pointer?
<pixelherodev>
`[1] 31100 invalid system call file test`
* pixelherodev
facepalms
<pixelherodev>
I keep forgetting that `file` is brokend
<pixelherodev>
andrewrk: what should I see?
<pixelherodev>
Seems fine to me
<pixelherodev>
`break _start` works, for instance
<andrewrk>
you should see full source and line info
<andrewrk>
you should be able to step over each line
<pixelherodev>
You don't though, right?
<pixelherodev>
Hmm
<andrewrk>
right and `info sources` shows nothing
<pixelherodev>
If I curl test.zig next to exectable, it works fine
<andrewrk>
orly
<pixelherodev>
Yeah
<pixelherodev>
info sources shows /home/noam/test{,.zig}
<andrewrk>
what gdb version
<pixelherodev>
9.2
<andrewrk>
there's the answer
<pixelherodev>
What are you on?
<andrewrk>
8.3.1
<pixelherodev>
8.c?
<pixelherodev>
x*
<pixelherodev>
Yeah
<pixelherodev>
That's probably it
<mikdusan>
8.dwarfless
<pixelherodev>
Can you upgrade?
<andrewrk>
doesn't matter. 8.3.1 is a comman version of gdb to be installed on people's systems
<pixelherodev>
... wrong question, yeah
<pixelherodev>
So we should support both 4 and 5 for now, right?
craigo has quit [Ping timeout: 256 seconds]
<pixelherodev>
Keep 5 support, default to 4
<andrewrk>
I don't see any reason to support more than one format
<pixelherodev>
Is there any eral differene between the two?
<pixelherodev>
real*
<andrewrk>
not really so far
<pixelherodev>
Then I agree, yeah
<pixelherodev>
No point in supporting two nearly identical formats
<andrewrk>
damn I didn't even get to see my own code working correctly
<pixelherodev>
There's got to be *something* that changes
<pixelherodev>
I can screenshot?
<mikdusan>
I would think dwarf version 2 and higher supported version spec... and gdb 8.3.x would at least check for supported dwarf version instead of just core'ing out
<andrewrk>
the incremental compilation dwarf thing is working so far :D just gotta add a bit more code for updating functions
<andrewrk>
readelf --debug-dump=decodedline also tells me it's good
<shachaf>
Does it work with lldb?
<andrewrk>
no
<andrewrk>
maybe it wants DW_AT_ranges
Kingsquee has quit [Read error: Connection reset by peer]
<andrewrk>
nope that wasn't it.
weka is now known as ggVGc
stripedpajamas has quit [Quit: sleeping...]
<alexnask[m]>
Incremental DWARF is so sick :)
ur5us has joined #zig
zigusr has quit [Ping timeout: 245 seconds]
<andrewrk>
ok looks like gdb doesn't like my extended opcode trick. it's a shame, arguably it's gdb doing it wrong
<andrewrk>
that's OK I still have the 2-byte NOP {DW_LNS_negate_stmt, DW_LNS_negate_stmt} trick left. it's just unfortunate because it means the padding bytes have to actually be written to the file which costs perf, and there's the annoying thing that they have to be in sets of 2 or else the stmt register gets incorrectly inverted
ur5us has quit [Remote host closed the connection]
<andrewrk>
I should file an issue asking for DWARFv6 to have a DW_LNS_jmp
ur5us has joined #zig
nikita` has joined #zig
marnix has quit [Ping timeout: 256 seconds]
bsrd has quit [Quit: WeeChat 2.9]
bsrd has joined #zig
<Snektron>
What about 16 byte nop
bsrd has quit [Client Quit]
bsrd has joined #zig
bsrd has quit [Client Quit]
bsrd has joined #zig
ur5us has quit [Ping timeout: 260 seconds]
trevarj has left #zig [#zig]
ur5us has joined #zig
bsrd has quit [Quit: WeeChat 2.9]
bsrd has joined #zig
<gruebite>
can i have variable number of struct members at comptime? :P like say `fn Foo(comptime nmembers: i32) type { return struct { fn foo1, fn foo2 } }`
<ikskuh>
no, that's not possible atm
<gruebite>
anything akin to attributes when going through an anytype?
<alexnask[m]>
(you could store the generated tuple + a list of "field names" in a struct and make a getter + some init function that takes an anonymous struct literal with the correct field names)
<gruebite>
nice, i'll take a look at this
<gruebite>
thanks
<alexnask[m]>
I will make a small StructType(fields...) to make this easier actually
<alexnask[m]>
Ive seen a couple of people that want @Type(.Struct) recently and this is the closest you can get so there ought to be some easy way to do it even if it relies on pretty... interesting, hacky things :P
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<ikskuh>
i still wonder if it's a good idea to forbid @Type(.Struct)
<alexnask[m]>
Its still not ruled out
<alexnask[m]>
But yeah I would argue its better than the abomination Im about to write
<alexnask[m]>
As long as you cant generate functions in the @Type(.Struct) scope
<ikskuh>
yeah, exactly
<ikskuh>
people are already hacking around that restriction
<ikskuh>
you, me, others
ur5us has quit [Ping timeout: 260 seconds]
forgot-password has joined #zig
<ikskuh>
if you are allowed to add symbols to a namespace (instead of just creating struct fields), you can also add functions
<alexnask[m]>
Well, the way the TypeInfo structs are made you couldnt actually reify a function even if you could reify other decls (which personally I think would be fine)
<ikskuh>
why that?
<ikskuh>
i could make a function taking `anytype` :D
<alexnask[m]>
The FnDecl doesnt include the function code
<alexnask[m]>
Only the signature, calling convention etc
<ikskuh>
you can make it a FnPtr though ;)
<alexnask[m]>
Even if it did you couldnt make a function that takes Self because Self doesnt exist yet (even if we had @specialize)
<ikskuh>
const fnptr
<alexnask[m]>
True
<ikskuh>
alexnask[m]: yeah, i'm aware of that
<alexnask[m]>
ikskuh: When I wrote TypeInfo I actually wanted to make it in a way that would support this (foolishly) but I never came up with an elegant design
<ikskuh>
heh
<ikskuh>
i think it's good that it's not possible :D
<ikskuh>
even if we could make a beautiful interface API with that in userspace
<forgot-password>
I have a semi-zig-related question regarding macos: When I build an executable the compiler says that it cannot find the libc headers. From "cc -E -Wp,-v -xc /dev/null" I can see that the include directory with the libc headers is missing in the list. The question is how can i tell it to look there? Last week it worked fine and I don't know what I did to fuck it up :/
<forgot-password>
Same thing when I compile a simple c-file which includes libc.h with clang. Somehow I removed (xcrun --show-sdk-path)/usr/include from its global include paths.
<alexnask[m]>
Hmm anonymous struct literals dont seem to have len
<alexnask[m]>
(StructType simple implementation, could be improved with default fields etc)
nycex has quit [Remote host closed the connection]
nycex has joined #zig
<ikskuh>
the hell :D
<ikskuh>
nice work!
<ifreund>
ok, that's pretty funky
<ifreund>
alexnask[m]: I think you sould link that in the issue for @Type(.struct)
<alexnask[m]>
Just did ;)
<ifreund>
nice
forgot-password has quit [Ping timeout: 246 seconds]
<ikskuh>
crazy :D
<ikskuh>
zig userland is just so overpowered :D
<alexnask[m]>
That Tuple hack unlocks a bunch of things
<ikskuh>
"But does your language have feature X?" - "No, but we have lib-X that implements that in userland"
<alexnask[m]>
Its the only way to take some iterable of types and make some runtime storage out of it afaict
<ikskuh>
why is the second parameter of StructType2 a anytype?
<ikskuh>
can't that be a []type ?
<alexnask[m]>
Yeah it could be []type, just left it anytype for flexibility :shrugs: Although I guess with this logic I could have made the names anytype too
<alexnask[m]>
Someone should use this in a big zig library so that we can strongarm @Type(.Struct) in /s
forgot-password has joined #zig
craigo has joined #zig
pmwhite has joined #zig
forgot-password has quit [Quit: leaving]
<danyspin97>
can I call a custom command in build.zig?
<ikskuh>
danyspin97: You probably want toi use addSystemCommand ;)
<danyspin97>
hmm, not sure
<ikskuh>
what do you need the command for?
<ikskuh>
as a build step?
<ikskuh>
like "pregenerate some files" or "package my output"?
<danyspin97>
adding a capability to an executable
<danyspin97>
after building it
<ikskuh>
yeah, then addSystemCommand is probably the right thing to do
<ikskuh>
it has access to the cache-itnernal paths
<andrewrk>
good news: I came up with an even better way than the 2-byte NOP thing, which involves skipping an arbitrary number of bytes by taking advantage of Extended Opcode User-Defined which encodes the length of the operation and expects consumers to ignore operations they don't support. So you can put any number here, and skip forward, over padding bytes, avoiding the need to write NOPs to disk.
<andrewrk>
Bad news: even though it's handled correctly in most places - binutils readelf, llvm-dwarfdump, zig's own stack trace code - it's not handled correctly by GDB, which silently ignores the .debug_line data when it sees a user-defined extended opcode.
<daurnimator>
sorry for the async<>iterator hackery.... I didn't feel like rewriting it
<Snektron>
andrewrk: you can stack the REP prefix any number of times
<Snektron>
Or one of the other prefixes
<Snektron>
`data16 data16 data16 data16 data16 nopw cs:[eax+eax*1+512]` should be 16 bytes
dermetfan has joined #zig
<Snektron>
Turns out its a CPU feature whether a stack of data16 can be efficiently decoded
<ifreund>
wasm is a lot simpler, I can just pad any expression with as many 1 byte nop instructions as I want
<Snektron>
oh you can do that on x86
<Snektron>
but then you have exactly that: n single-byte nop instructions
<Snektron>
which takes up to n cycles
<Snektron>
These long nops actually only take a single cycle
<ikskuh>
daurnimator: not sure if i like it that way
<Snektron>
So you can do nothing, but more fficiently
<daurnimator>
ikskuh: is that because of the iterator thing? >.<
<ifreund>
Snektron: ah, I see
<ifreund>
that is pretty neat
<ikskuh>
daurnimator: yeah
<Snektron>
its mainly for alignment purposes of code
<daurnimator>
also I realised it can be a little terser by putting the `resume frame` in the loop continuation: `while (item) |result| : (resume frame) {`
<daurnimator>
ikskuh: with an actual state machine you wouldn't need it
<ikskuh>
the problem i see with this code is that it's blocking
<daurnimator>
ikskuh: what is?
<ikskuh>
i cannot parse half an entry and continue with whatever i was doing
<ikskuh>
the usage is blocking
<daurnimator>
can't you?
<ikskuh>
well, the code right now is definitly blocking
<ikskuh>
so reading a single byte ':', then receiving a single byte 'F' will block the outer scope until another character is available in the stream
<ikskuh>
the idea with FiFo is more elegant imho
<ikskuh>
because i can *stop* parsing and doing something else in the meantime without having to utilize async code
<daurnimator>
You can though.... just don't resume until you want more
<ikskuh>
the point is: maybe i don't know when i *want* more
<ikskuh>
but i want to react to when i *have* more
<ikskuh>
imagine you have a really slow and sloppy connection to some end point
<daurnimator>
I don't think that's a good idea
<daurnimator>
you shouldn't be able to force your downstream to consume you
<ikskuh>
hm?
<daurnimator>
the consumer should be the one that causes forward progress.
<ikskuh>
so?
<ikskuh>
the parser should still be tolerant against incomplete data being fed into it
<ikskuh>
and not block then
<daurnimator>
yes.
<ikskuh>
until enough data is there
<daurnimator>
yes.
<ikskuh>
the ihex example right now does this though
<ikskuh>
which is my main critique
<daurnimator>
not if you give it an async stream
<ikskuh>
then i have async code which is imho not always desirable
<daurnimator>
why?
<ikskuh>
it should be possible, but i for myself won't be using a lot of async
<ikskuh>
because i find it harder to read and reason about
<andrewrk>
all we gotta do is wait 2 years until it is widely available everywhere ;)
<alexnask[m]>
Quick fix though, nice
<pixelherodev>
lol
<pixelherodev>
Maybe it'll get backported?
<pixelherodev>
... that was stupid of me, sorry.
<pixelherodev>
I know better than that
marnix has joined #zig
<pixelherodev>
That was really impressively fast though
<pixelherodev>
Kudos to them
<pixelherodev>
andrewrk: I think it's your turn again :)
<Snektron>
andrewrk: oh, my bad
nvmd has joined #zig
<pixelherodev>
Hmm
<pixelherodev>
Is it possible to have standalone DWARF info?
<pixelherodev>
Without ELF?
<Sahnvour>
I think mingw can do dwarf
<pixelherodev>
hmm
<pixelherodev>
"Independent of object file formats"
<Sahnvour>
that I don't know :)
<pixelherodev>
It is :)
<pixelherodev>
I just checked
euandreh has quit [Ping timeout: 272 seconds]
<pixelherodev>
andrewrk: idea: we should build DWARF info in self-hosted *independent of the linker target*, and the ELF backend should embed that info as part of flush()
<pixelherodev>
This would allow, for instance, flushing that info to its own file when we're not targeting ELF
nikita` has quit [Quit: leaving]
<Sahnvour>
what would be the usecase ? only target one debug info format and use it on all platforms from zig ?
<andrewrk>
this idea would not do incremental compilation, so it's a non-starter
<pixelherodev>
andrewrk: Why wouldn't it?
<pixelherodev>
File.updateDecl would handle it before routing downwards
<pixelherodev>
Sahnvour: yeah, basically
<pixelherodev>
The entire idea is incrementally compiled debug info independent of object format
nikita` has joined #zig
<Sahnvour>
you'd still need "native" debug format to use platform's tools though, for example PDBs on windows
<andrewrk>
yeah. better to integrate with the target's tooling conventions
euandreh has joined #zig
<pixelherodev>
So what I'm hearing is
<pixelherodev>
"Convince Microsoft to use DWARF and then your idea is valid?"
<pixelherodev>
s/?"/"?
marnix has quit [Read error: Connection reset by peer]
<Sahnvour>
that'd be a mean way to put it haha, but people expect their native dev tools to work especially since stage1 complied with them
<pixelherodev>
;P
stripedpajamas has quit [Quit: sleeping...]
stripedpajamas has joined #zig
pmwhite has quit [Remote host closed the connection]
dermetfan has joined #zig
<gruebite>
is it fooUint or fooUInt?
wootehfoot has joined #zig
<ifreund>
gruebite: the former afaik
<ifreund>
you'd definitely do foo_uint over foo_u_int
<alexnask[m]>
I think Cygwin gdb uses dwarf :p
<ifreund>
I reall hope #1097 gets accepted though, I'm really not a fan of camelCase function names
<gruebite>
it's a method :P
<gruebite>
makeUint or makeUInt
<ifreund>
yeah, so makeUint() is what I'd say
wootehfoot has quit [Read error: Connection reset by peer]
r4pr0n has joined #zig
stripedpajamas has quit [Remote host closed the connection]
ur5us has joined #zig
Akuli has quit [Quit: Leaving]
casaca has quit [Remote host closed the connection]
casaca has joined #zig
KKRT has quit [Quit: KKRT]
dermetfan has quit [Ping timeout: 240 seconds]
<pixelherodev>
The awesomest thing ever is being able to use a git repo on a personal server :D
<torque>
psh, cool kids use git repos stored in a different folder on the same machine
<ifreund>
branches? never heard of em. I just make more clones :P
<pixelherodev>
ifreund: I'm working branchless rn actually ;)
<leeward>
Well crap. Looks like I'm in the market for a new laptop.
<ifreund>
well if you only work on one thing at a time, you don't reall need branches
<ifreund>
s/reall/really
<pixelherodev>
Branches are just references are just commit IDs
<pixelherodev>
ifreund: I refactor frequently at this point
<pixelherodev>
Largely because Zig has ingrained that habit in me TBH
<mikdusan>
git worktree ftw
<ifreund>
yes branches are just labels for commits
<shakesoda>
branches are a lot more of a headache if you don't work on one thing at a time
<ifreund>
I find this useful to organize work on mulitple things
<shakesoda>
i am vastly too scatterbrained for that lol
<shakesoda>
so usually i only make branches after the fact in order to submit prs