| lkcl | urrr fiinally i think i've found the bug in dcache | 10:21 |
|---|---|---|
| lkcl | two stores one after the other in the same page has a special case in microwatt dcache, and the address was getting corrupted | 10:22 |
| lkcl | frickin ellfire that was a pig to track down | 10:40 |
| ghostmansd | Hi folks, want to ask your opinion. Would that be a completely awful and forbidden hack in binutils? | 15:04 |
| ghostmansd | https://pastebin.com/sGuLZ04j | 15:04 |
| ghostmansd | I'd like to drop -Wno-missing-initializers and at the same time avoid calling `malloc` to allocate a bigger structure. First, allocating stuff we already have for granted is already dubious; second, I then have to cleanup it (at least to be a good citizen), and cleanup routine in binutils is a somewhat messy stuff (basically I'll have to touch several files to make it work, in form of macro). | 15:07 |
| ghostmansd | To me this idea looks like a bit dubious, frankly speaking; at the same time, I'd like to touch vanilla binutils as less as possible so that thing is really kept as an extension. | 15:08 |
| ghostmansd | Also, to be entirely honest, using `uint64_t` is _also_ a non-standard, but at least it's lesser evil than `#pragma`, eh? | 15:09 |
| lkcl | yyeah don't do that :) | 15:49 |
| lkcl | use & of the struct or *(&ppc->svp64_thing) = y | 15:50 |
| lkcl | or, better, create a union and assign to the uint64_t | 15:50 |
| ghostmansd | All variants but that would require a new field to be initialized... | 16:00 |
| ghostmansd | That's why I ever suggested this. | 16:00 |
| ghostmansd | cf. lines 103, 104 and 112 at https://pastebin.com/sGuLZ04j | 16:01 |
| lkcl | urr | 16:02 |
| ghostmansd | Here we have an array of powerpc_opcodes: https://sourceware.org/git/?p=binutils.git;a=blob;f=opcodes/ppc-opc.c;h=82f4f1297cc2cbe7892043964193b0e3ea480609;hb=HEAD#l2779 | 16:03 |
| ghostmansd | Ah wait, that's not the recent | 16:05 |
| ghostmansd | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-opc.c;h=a424dd924dec28d173a4abfc85ae134ba83ad863;hb=HEAD#l4353 | 16:05 |
| lkcl | and also gives "XML Parsing error" :) | 16:05 |
| ghostmansd | Also there are more entries, e.g. prefix_opcodes, vle_opcodes, et al. | 16:06 |
| ghostmansd | These all are merged into ppc_hash | 16:06 |
| ghostmansd | Of course as static elements, w/o allocation involved | 16:06 |
| ghostmansd | or, to be exact, the hash itself allocates, but entries are mapped as is | 16:07 |
| lkcl | the file's so large it's taking several minutes to load on my internet connection | 16:07 |
| ghostmansd | OK, don't really bother, the essense is that it's a damn huge pack of powerpc_opcodes :-) | 16:08 |
| lkcl | ok yes, ah ha! | 16:08 |
| ghostmansd | Basically all insns that PPC has | 16:08 |
| lkcl | if there are some extensions like that already it would be kinda ok to do the same thing | 16:09 |
| ghostmansd | They all re-use the same structure layout | 16:09 |
| ghostmansd | we're the only ones who need yet another 64 bits :-( | 16:09 |
| ghostmansd | and, of course, since we change the structure layout... | 16:09 |
| ghostmansd | the whole thing just breaks at compilation when I add a new field | 16:10 |
| ghostmansd | due to the fact that some weirdo (me) doesn't want to update that huge file to add an empty uint64 to each entry of each damned array | 16:10 |
| ghostmansd | (and, of course, I think we shouldn't) | 16:10 |
| ghostmansd | at the same time, whilst I don't want to update records... | 16:11 |
| lkcl | sounding like a separate hashtable to e | 16:11 |
| lkcl | me | 16:11 |
| ghostmansd | would that be OK? | 16:11 |
| ghostmansd | I mean, that's what I wanted to do initially | 16:11 |
| ghostmansd | https://sourceware.org/git/?p=binutils.git;a=blob;f=gas/config/tc-ppc.c;h=6b54f5ad8ebcb979abe24e9428d65246a6631c8e;hb=HEAD#l2507 | 16:12 |
| ghostmansd | that's the place we want to hack | 16:12 |
| ghostmansd | cf. `opcode = (const struct powerpc_opcode *) hash_find (ppc_hash, str);` | 16:12 |
| ghostmansd | the code we build atop keeps the stuff working the same, and we _can_ re-use the same hash, if the structure is updated to incorporate the svp64 field | 16:13 |
| ghostmansd | but, if not, we have to check another hash | 16:13 |
| ghostmansd | if that's OK, I can update the code so that we have another hash entry | 16:14 |
| lkcl | yeah i'd do a 2nd hash, keep it completely separte | 16:14 |
| ghostmansd | I think it won't be the issue: as I mentioned before, we anyway suck at cache there, so having another hash'd be OK | 16:14 |
| ghostmansd | OK, got it, let's proceed with the original plan then :-) | 16:14 |
| lkcl | doh :) | 16:15 |
| ghostmansd | In csvs, do we have an option to understand which insns might have a dot there? | 16:26 |
| ghostmansd | I mean, we have only `add` entry, but not `add.`; I'd like to output both, though, but at the same time avoid crap like `addg6s.`. | 16:27 |
| ghostmansd | Or well, I'm wrong. Not CSVs, but, rather, openpower.decoder.power_svp64.SVP64RM, since we use it. | 16:28 |
| ghostmansd | The entries would be the same if I'm not mistaken; however, I'd not need to add the C code which drops the dot, and simply will look the name up as is. | 16:30 |
| ghostmansd | Well, CSVs, after all: `ISA = _SVP64RM(); for record in ISA.get_svp64_csv(path): generate_c_code(record)` | 16:34 |
| ghostmansd | FWIW, separating to standalone struct looks real cool: `str_hash_insert (svp64_hash, svp64->name, &svp64->record, 0)` is damn well evident. | 16:46 |
| lkcl | there's an RC field in the csv | 16:52 |
| lkcl | it identifies when you can add 'o' or '.' or 'o.' | 16:52 |
| lkcl | look at ISACaller.get_assembly_name() | 16:53 |
| lkcl | there is also similar reconstruction based on the LK field | 16:54 |
| lkcl | and also the AA field | 16:54 |
| ghostmansd[m] | Thanks lkcl! This is exactly what I need. | 17:44 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!