Contribute
Register

Native DSDT/AML IDE & Compiler: MaciASL Open Beta

Status
Not open for further replies.

RehabMan

Moderator
Joined
May 2, 2012
Messages
183,805
Motherboard
Intel DH67BL
CPU
i7-2600K
Graphics
HD 3000
Mac
  1. MacBook Air
Mobile Phone
  1. iOS
Weird bug in latest:

Code:
DefinitionBlock ("dsdt.aml", "DSDT", 1, "TEST", "TEST", 0x00000000)
{
    Scope (BB.X1)
    {
        Device (X)
        {
            Method (M1, 0, NotSerialized)
            {
            }
            Method (M2, 0, NotSerialized)
            {
            }
        }
    }
}

Parsed as:
Screen Shot 2014-06-22 at 11.21.33 AM.png

Expect: M1 and M2 are direct children of Device(X).

Change code to:
Code:
DefinitionBlock ("dsdt.aml", "DSDT", 1, "TEST", "TEST", 0x00000000)
{
    Scope (B.X1)
    {
        Device (X)
        {
            Method (M1, 0, NotSerialized)
            {
            }
            Method (M2, 0, NotSerialized)
            {
            }
        }
    }
}

And correct parsing is achieved:
Screen Shot 2014-06-22 at 11.23.00 AM.png

Edit: Confirmed caused by latest commit.
 

SJ_UnderWater

Moderator
Joined
Dec 3, 2010
Messages
461
Motherboard
Gigabyte GA-H55M-S2V
CPU
Intel i3-530
Graphics
HIS HD 6570
Mac
  1. iMac
Classic Mac
Mobile Phone
  1. Android
Tablesets are not as universal as disassembly via 'iasl -da' because you cannot disassemble SSDTs properly using MaciASL since it does not pass the other SSDTs/DSDT as context to the iasl disassembler when loading an SSDT from a tableset.
This could easily have been posted as an issue months ago, considering I already perform this for DSDTs. See below for the resolution.
In addition, tablesets cannot be saved once one or more patches are applied. Because the (patched) SSDT cannot be disassembled standalone, further edits using the resulting AML are not possible.
Tablesets are immutable by design, and I can see no point in recompiling a patched AML originally taken from a one. Surely users requesting patches send their tablesets to a patcher, who then examines and tries patching the tables? What would someone do afterwards with a patched AML while not on the machine it came from?
The best strategy is to disassemble with 'iasl -da' all tables, and then work with the resulting *.dsl files from that point on.
This is bad practice for several reasons, which I mentioned. One which I didn't mention is that the AML extracted from memory is the "true" table: a DSL file is only one particular version of iASL's interpretation of that AML file, and is therefore never authoritative. Depending on which version(s) of iASL are used by the user and patcher, the DSL file can be very different; an immutable collection of AML blobs (a tableset) is the only guarantee. Additionally, I only see two cases where resolution is necessary: the user is at the machine in question, examining and editing tables; and a patcher examining and building patches for a machine not available to them. In the first case the user is simply at their machine, in the second the patcher needs an original copy of all tables to build the patch.
Weird bug in latest:
Edit: Confirmed caused by latest commit.
I realized this after pushing the commit, and on Saturday started and finished a rewrite of MaciASL. Once it passes testing, I will push the development branch for others to try, which will eventually merge onto master as v1.4. It contains a fix for the strict name check (Scopes are often longer than four characters), among other issues like the unreported SSDT resolution issue.
 

RehabMan

Moderator
Joined
May 2, 2012
Messages
183,805
Motherboard
Intel DH67BL
CPU
i7-2600K
Graphics
HD 3000
Mac
  1. MacBook Air
Mobile Phone
  1. iOS
This could easily have been posted as an issue months ago, considering I already perform this for DSDTs. See below for the resolution.

I mentioned this previously. Not on this thread, but elsewhere (modhouse).

Tablesets are immutable by design, and I can see no point in recompiling a patched AML originally taken from a one. Surely users requesting patches send their tablesets to a patcher, who then examines and tries patching the tables? What would someone do afterwards with a patched AML while not on the machine it came from?

It is often necessary to apply additional patches to a patched AML to make further corrections for issues not originally contemplated. As mentioned, in AMLs with complex relationships, this is not possible because of the inaccuracy of standalone disassembly. The only way to deal with this using tablesets is to always go back to the original tableset and apply all patches previously used to each file in addition to the new ones (cumbersome). Saving the .dsl files and treating them as source code (which they are) is a better strategy.

With my own setups, I use an automated process, arguably more developer oriented, using patchmatic and make. For an example, see: https://github.com/RehabMan/Lenovo-U430-Touch-DSDT-Patch

This is bad practice for several reasons, which I mentioned.

We have a difference of opinion here. I'll leave it at that.
 
Joined
May 13, 2012
Messages
22
Motherboard
Yosemite
CPU
i3
Graphics
Geforce GTX660OC
Mac
Classic Mac
Mobile Phone
Hey sj_underwater !

First of all thanks for the fast patching!
Now I am able to apply any patch but my DSDT gives much more errors then before.

Even my fixed DSDT has about 48 errors of the same type "object does not exist" which weren´t there before!

Is this still a bug of maciasl or is my dsdt pretty messed up?

Ciao
 

Attachments

  • Untitled.tiff
    284.2 KB · Views: 152

RehabMan

Moderator
Joined
May 2, 2012
Messages
183,805
Motherboard
Intel DH67BL
CPU
i7-2600K
Graphics
HD 3000
Mac
  1. MacBook Air
Mobile Phone
  1. iOS
Hey sj_underwater !

First of all thanks for the fast patching!
Now I am able to apply any patch but my DSDT gives much more errors then before.

Even my fixed DSDT has about 48 errors of the same type "object does not exist" which weren´t there before!

Is this still a bug of maciasl or is my dsdt pretty messed up?

Ciao

Use the previous version of MaciASL, but remove the comment pointed out in post #249 (and all others like it).
 

SJ_UnderWater

Moderator
Joined
Dec 3, 2010
Messages
461
Motherboard
Gigabyte GA-H55M-S2V
CPU
Intel i3-530
Graphics
HIS HD 6570
Mac
  1. iMac
Classic Mac
Mobile Phone
  1. Android
Since the patch does not apply to MaciASL, it has been moved to http://www.tonymacx86.com/mavericks...-7x37-clover-install-guide-26.html#post832916 Please keep this thread on-topic, that includes issues which only affect MaciASL as-shipped.

The development branch has been pushed, from work completed last weekend. Any new issues should be tracked against that branch, and reported here. development will eventually merge on to master as v1.4
I mentioned this previously. Not on this thread, but elsewhere.
If you're talking about your mention ~20 days ago, that's not what I mean, considering you were unaware of external resolution in MaciASL until I pointed it out, instead running iASL directly. There is a huge gap developing whereby you're maintaining a diverging downstream product while not contributing upstream or notifying me proactively of issues, sending users my way without explanation. If you're counseling users against my advice to use DSLs, generated with a version of iASL I don't ship (and therefore don't support, at least implicitly), on a downstream product (which I certainly don't support), but still apply my commits to your source, you have a responsibility to keep track of those changes. If you identify an issue which exists in MaciASL, then post it here.
It is often necessary to apply additional patches to a patched AML to make further corrections for issues not originally contemplated. As mentioned, in AMLs with complex relationships, this is not possible because of the inaccuracy of standalone disassembly. The only way to deal with this using tablesets is to always go back to the original tableset and apply all patches previously used to each file in addition to the new ones (cumbersome). Saving the .dsl files and treating them as source code (which they are) is a better strategy.
I noticed you didn't answer my question. Why is this happening, why are you re-patching a patched file? If you're using a "source code" strategy, that strongly implies exactly what I was saying: the tableset and patches are the "source", the patched AML is the "binary".
With my own setups, I use an automated process, arguably more developer oriented, using patchmatic and make. For an example, see: https://github.com/RehabMan/Lenovo-U430-Touch-DSDT-Patch
Developers use IDEs, consumers use automated solutions.
 

RehabMan

Moderator
Joined
May 2, 2012
Messages
183,805
Motherboard
Intel DH67BL
CPU
i7-2600K
Graphics
HD 3000
Mac
  1. MacBook Air
Mobile Phone
  1. iOS
Since the patch does not apply to MaciASL, it has been moved to http://www.tonymacx86.com/mavericks...-7x37-clover-install-guide-26.html#post832916 Please keep this thread on-topic, that includes issues which only affect MaciASL as-shipped.

It was clearly directly related to the use of MaciASL with newer iasl, but whatever, this is your thread.

The development branch has been pushed, from work completed last weekend. Any new issues should be tracked against that branch, and reported here. development will eventually merge on to master as v1.4

I had issues with this version, in particular the isInjected code, which crashed when opening standalone files. I replaced it with:
Code:
+(NSString *)isInjected:(NSURL *)url {
    //return [[self.tableset allKeysForObject:[NSData dataWithContentsOfURL:url]] objectAtIndex:0];
    if (!self.tableset)
        return nil;
    NSArray* allkeys = [self.tableset allKeysForObject:[NSData dataWithContentsOfURL:url]];
    if (!allkeys || ![allkeys count])
        return nil;
    return [allkeys objectAtIndex:0];
}

I'm sure the above can be "simplified" somewhat by taking advantage of the fact that you can send messages to nil, but I'm no Obj-C expert so I didn't attempt any such "optimization."

BTW, is there anything in particular you'd like testing to focus on with this new version in the 'development' branch?

If you're talking about your mention ~20 days ago, that's not what I mean, considering you were unaware of external resolution in MaciASL until I pointed it out, instead running iASL directly.

You said I never notified you of the deficiency with regard to external resolution with SSDTs. I was just pointing out that, in fact, I had notified you and therefore your characterization that I'm not reporting issues as discovered is incorrect.

I'm still running iasl directly and have no plans to start using MaciASL tablesets instead.

There is a huge gap developing whereby you're maintaining a diverging downstream product while not contributing upstream or notifying me proactively of issues, sending users my way without explanation.

There is no "huge gap." Look at a diffmerge of the projects and you'll see the differences are almost entirely a result of PATCHMATIC ifdef.

I do not feel it is my responsibility to report bugs to you that other users experience while using MaciASL. That responsibility falls squarely on them and becomes an issue between you and that user, including whether they provide adequate explanation of the problem.

When I report issues to you, I usually spend considerable time investigating and reducing the repro case. Evidently you do not appreciate this. I do not have the time to do that for every issue each user might discover. It is unreasonable for you to expect me to serve as conduit for all bugs discovered by users that I might come in contact with during the process of helping them.

If you're counseling users against my advice to use DSLs, generated with a version of iASL I don't ship (and therefore don't support, at least implicitly), on a downstream product (which I certainly don't support), but still apply my commits to your source, you have a responsibility to keep track of those changes. If you identify an issue which exists in MaciASL, then post it here.

Since MaciASL provides a file association for .DSL, it should be able to open and manipulate any DSL file regardless of how the file was generated. This includes new versions of iasl, as you can't be certain users of MaciASL are not using the tool in ways not according to your personal preferences/practices.

I regularly update my fork of the Intel iasl repo, as there are useful fixes there.

I noticed you didn't answer my question. Why is this happening, why are you re-patching a patched file?

Your question was not relevant to the issue being discussed. As I tried to explain, it is common to apply one patch during the development of a "patch set" for a given computer, only to discover additional patches to the same file are later required. It is for this reason that I use a "source code" strategy where such patches are applied only DSL files and built into AML for testing. This avoids later secondary disassembly, which as you know, is not reliable without the other files in the table set as reference.

If you're using a "source code" strategy, that strongly implies exactly what I was saying: the tableset and patches are the "source", the patched AML is the "binary".

Using the tableset requires all patches to be applied at once. This is cumbersome, time consuming, and error prone. It is why I use patchmatic and make to automate the process. I would never consider using MaciASL tablesets during the the development process.

Developers use IDEs, consumers use automated solutions.

I'm a developer. I use a combination of IDEs *and* automated solutions such as make or shell scripts. IDEs are not the best tools for all development tasks. I use the most appropriate tools to accomplish the given task. I suspect you do too.

MaciASL is a great tool but I don't find it adequate, by itself, for end-to-end development of complex ACPI patches and prefer to use a mix-n-match approach as it fits my needs.
 
Joined
Jul 3, 2012
Messages
3
Motherboard
X399M Taichi
CPU
2920X
Graphics
RX 580 Nitro+
Mac
  1. MacBook
Mobile Phone
  1. Android
  2. iOS
Hey everyone!

It seems I came across a bug in MaciASL (or rather the patcher part of it) that prevents applying a patch to my extracted DSDT. When the decompiler adds comments for buffers and the hex-values correspond to the character "}" it can cause trouble. You can replicate the issue with the following two snippets:

The B1B2 and B1B4 method patches from the battery status guide:
Code:
into method label B1B2 remove_entry;
into definitionblock code_regex . insert
begin
Method (B1B2, 2, NotSerialized) { Return(Or(Arg0, ShiftLeft(Arg1, 8))) }\n
end;

into method label B1B4 remove_entry;
into definitionblock code_regex . insert
begin
Method (B1B4, 4, NotSerialized)\n
{\n
    Store(Arg3, Local0)\n
    Or(Arg2, ShiftLeft(Local0, 8), Local0)\n
    Or(Arg1, ShiftLeft(Local0, 8), Local0)\n
    Or(Arg0, ShiftLeft(Local0, 8), Local0)\n
    Return(Local0)\n
}\n
end;

An offending DSDT snippet:
Code:
DefinitionBlock ("DSDT.aml", "DSDT", 2, "OEMID  ", "TableID ", 0x00000000)
{
    Scope (_SC)
    {
        Device (DEV1)
        {
            Name (BUFF, Buffer (0x000A)
            {
                /* 0000 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /* ...}.... */
                /* 0008 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /* ...}.... */
                /* 0010 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00   /* ...}.... */
            })
        }
    }
}

When the patch is applied to the DSDT snippet, you will notice that the methods are inserted into the buffer. When the "}" characters are removed from the comments, the patch works as expected. I also tried to write a workaround-patch, but it seems impossible to match the "}" character inside the comments using the patcher grammar.

Regards
herrritschwumm
 

RehabMan

Moderator
Joined
May 2, 2012
Messages
183,805
Motherboard
Intel DH67BL
CPU
i7-2600K
Graphics
HD 3000
Mac
  1. MacBook Air
Mobile Phone
  1. iOS
Hey everyone!

It seems I came across a bug in MaciASL (or rather the patcher part of it) that prevents applying a patch to my extracted DSDT. When the decompiler adds comments for buffers and the hex-values correspond to the character "}" it can cause trouble. You can replicate the issue with the following two snippets:

The B1B2 and B1B4 method patches from the battery status guide:
Code:
into method label B1B2 remove_entry;
into definitionblock code_regex . insert
begin
Method (B1B2, 2, NotSerialized) { Return(Or(Arg0, ShiftLeft(Arg1, 8))) }\n
end;

into method label B1B4 remove_entry;
into definitionblock code_regex . insert
begin
Method (B1B4, 4, NotSerialized)\n
{\n
    Store(Arg3, Local0)\n
    Or(Arg2, ShiftLeft(Local0, 8), Local0)\n
    Or(Arg1, ShiftLeft(Local0, 8), Local0)\n
    Or(Arg0, ShiftLeft(Local0, 8), Local0)\n
    Return(Local0)\n
}\n
end;

An offending DSDT snippet:
Code:
DefinitionBlock ("DSDT.aml", "DSDT", 2, "OEMID  ", "TableID ", 0x00000000)
{
    Scope (_SC)
    {
        Device (DEV1)
        {
            Name (BUFF, Buffer (0x000A)
            {
                /* 0000 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /* ...}.... */
                /* 0008 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,  /* ...}.... */
                /* 0010 */  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00   /* ...}.... */
            })
        }
    }
}

When the patch is applied to the DSDT snippet, you will notice that the methods are inserted into the buffer. When the "}" characters are removed from the comments, the patch works as expected. I also tried to write a workaround-patch, but it seems impossible to match the "}" character inside the comments using the patcher grammar.

Regards
herrritschwumm

Use a version of iasl that doesn't have that "feature"...

See here: http://www.tonymacx86.com/yosemite-laptop-support/152573-guide-patching-laptop-dsdt-ssdts.html
 
Status
Not open for further replies.
Top