- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 13 2020
Sep 16 2016
In D2535#163954, @adrian wrote:I committed the pagemask enumeration/printing logic to -head a while ago. We should gather some dmesg's from various embedded MIPS boards.
IIRC, some of the mips24kc parts were only doing 4k pages.. :(
Mar 13 2016
Yes, the superpage size should be 2M (PDRSIZE) for mips64. This looks correct. I am not sure it matters for mips32 given there is no superpage support for it yet. The way it is done for mips64 (see https://reviews.freebsd.org/D2535 ) may not work for mips32 given the limited number of available PTE bits. Of course, the mips64 superpage implementation was designed to support multiple superpage sizes (more than just 2M) although only one superpage size is currently implemented. I imagine with mips32 only one superpage size would be supported.
Feb 3 2016
I will fix this in LLDB. Thanks Warner!
In D5171#110109, @imp wrote:Also, the LLVM parser is wrong.
case llvm::ELF::EF_MIPS_ARCH_3: case llvm::ELF::EF_MIPS_ARCH_4: case llvm::ELF::EF_MIPS_ARCH_5: case llvm::ELF::EF_MIPS_ARCH_64: return (endian == ELFDATA2LSB) ? ArchSpec::eMIPSSubType_mips64el : ArchSpec::eMIPSSubType_mips64;This is incorrect. These arch (at least the first two) are both 32-bit and 64-bit. You know what arch you are executing based on the e_ident[EI_CLASS} telling you 32 vs 64 bit.
32-bit mips FreeBSD binaries are MIPS-3. And that's correct. And LLVM doesn't grok that. So the LLVM parser also needs work.
In D5171#110106, @imp wrote:I don't like this interface. The CPU specific eflags aren't a property of the CPU, but rather are a property of how the binary was compiled. These should be in the header for the binary being executed, which is completely ignored. On arm, there's at least two flavors we support executing today. On mips we support 3 different binary ABIs. And we wish to support more flavors of those ABIs (soft-float, hard-float, cheri) and you can't know based on the kernel which one of these you are running.
Jun 18 2015
Jun 14 2015
Jun 8 2015
In D1971#52645, @mjg wrote:the problem of holding a non-sleep lock during a page fault as reported by witness
What page fault?
Jun 5 2015
Jun 4 2015
This has been replaced by https://reviews.freebsd.org/D2123
This has been replaced by https://reviews.freebsd.org/D2123
May 13 2015
Mar 24 2015
Mar 19 2015
Mar 2 2015
This one should apply cleanly to head.
Feb 27 2015
I don't know why http://svnweb.freebsd.org/base/head/sys/kern/imgact_binmisc.c?r1=264282&r2=271141&pathrev=271141 showed up in this diff. Weird.
Simplify change by just acquiring exclusive lock and not trying to upgrade it.
Feb 26 2015
Jul 28 2014
I would "#if 0" the dead code for now (rather than adding a 'return 0') to avoid upsetting the compiler god. Other than that, it looks fine.