[fasmg] namespace traversal bug or ?

Index > Main > [fasmg] namespace traversal bug or ?

Author

Thread

sylware

Joined: 23 Oct 2020
Posts: 462
Location: Marseille/France

sylware 01 Oct 2021, 17:48

Here is a code sample:

Code:

include 'format/format.inc'
format.elf64
use64
section '.text' executable writeable align 16
_start:
    mov rax, [a.b.c.mydata]
section '.data' writeable align 64
namespace a
        c: rq 1
        namespace b
                namespace c
                        mydata: rq 1
                end namespace
        end namespace
end namespace

I get: "Error: symbol 'a.b.c.mydata' is undefined or out of scope"

but if I comment out: ";c:rq 1"

It seems to assemble fine.

What do I still not understand about namespace traversal? Sad

01 Oct 2021, 17:48

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 01 Oct 2021, 21:17

When "c" is not defined, it defaults to symbol in current namespace, so "namespace c" looks up the namespace of "a.b.c" - but when you have "c" symbol defined (with "c:") at another level - in this case as "a.c", you end up switching to it instead. The symbol that gets defined then is "a.c.mydata".

An important thing to note is that NAMESPACE directive does not create the namespace, it just switches temporarily to a namespace that it finds through the provided identifier. You do not nest NAMESPACE blocks to create a similarly nested tree, each of them just switches the base namespace and then switches back.

It may help to think of "namespace c"/"end namespace" block as meaning do something in namespace called c, not make a namespace c here. It refers to an existing symbol (though when none is found, it picks one in current namespace, even if undefined).

Therefore, if you need to reliably make a tree of nested namespaces, you should ensure to always have them specified through defined symbols, for example:

Code:

a: namespace a
        c: rq 1
        b: namespace b
                c: namespace c
                        mydata: rq 1
                end namespace
        end namespace
end namespace

Perhaps it would have been less confusing if I named this directive NAMESPACEOF instead of plain NAMESPACE. I could still introduce that as a synonym.

01 Oct 2021, 21:17

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20459
Location: In your JS exploiting you and your system

revolution 01 Oct 2021, 22:38

Tomasz Grysztar wrote:

Perhaps it would have been less confusing if I named this directive NAMESPACEOF instead of plain NAMESPACE. I could still introduce that as a synonym.

Maybe: GOTONAMESPACEOFORFAKEANEWONEHERE

01 Oct 2021, 22:38

bitRAKE

Joined: 21 Jul 2003
Posts: 4079
Location: vpcmpistri

bitRAKE 02 Oct 2021, 14:03

The brief name for the directive makes sense in light of the overall philosophy used - which is analogous with assembly language programming. Directives tend to do what is sufficient and not too much as to be overly restrictive, imho.

02 Oct 2021, 14:03

sylware

Joined: 23 Oct 2020
Posts: 462
Location: Marseille/France

sylware 02 Oct 2021, 15:15

@Tomasz okay! My mental picture of fasmg objects is improving. Then if the "in-between" namespaces do not exist, "where" is going the definition then? The identifier is actually "a.b.c.mydata" in the "top" namespace?

@others: usually, it is just a matter of tuning to the manual.

02 Oct 2021, 15:15

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 02 Oct 2021, 17:31

sylware wrote:

Then if the "in-between" namespaces do not exist, "where" is going the definition then?

All the namespaces always exist, the only thing that changes is your ability to refer to them. You specify a namespace by pointing to a symbol, and this may be a symbol which is anywhere in the hierarchy, as long as you are able to refer to it somehow.

And - by design - you can refer to symbols only in relative terms, which allows to encapsulate any module in a way that is not apparent from within. When you write something like "a.b.c", it is never absolute, it is anchored at the nearest "a" that is defined and visible to you (and if no "a" is defined anywhere, it is assumed to mean the one in the current namespace, even if it never gets defined).

02 Oct 2021, 17:31

sylware

Joined: 23 Oct 2020
Posts: 462
Location: Marseille/France

sylware 02 Oct 2021, 20:05

I got several times the strong encapsulation feature (I never did expect something else to say the least).

Then, what are the general rules for hierarchical identifiers? For instance "a.b.c.d". I guess it will start from "a"
: if no instance of expression class with such symbol in current namespace is found , it will start to walk upward the namespaces until one is found. If one is found, it will then be used as an "anchor" to walk downward the namespaces, but if b does not have any instance of expression class associated with it in namespace a, I'll get an error, right? Because it seems I can walk downward the namespace hierarchy without the need to have an instance of expression class associated with each symbol at each depth. Wrong?

02 Oct 2021, 20:05

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 02 Oct 2021, 21:55

sylware wrote:

Then, what are the general rules for hierarchical identifiers? For instance "a.b.c.d". I guess it will start from "a"
: if no instance of expression class with such symbol in current namespace is found , it will start to walk upward the namespaces until one is found. If one is found, it will then be used as an "anchor" to walk downward the namespaces, but if b does not have any instance of expression class associated with it in namespace a, I'll get an error, right?

No, the presence of defined symbol only matters for the "anchor", the first name. The dot always implies the direct relationship, so "a.b" is always going to mean "b" in the namespace of "a" (whichever "a" ends up being used), even if "b" symbol is never defined there.

02 Oct 2021, 21:55

sylware

Joined: 23 Oct 2020
Posts: 462
Location: Marseille/France

sylware 03 Oct 2021, 15:26

Allright!

In the light of this thread, where in the manual those topics are explicited?
Because I did read a few times the manual, but it is so dense, I always manage to forget where to look and I end up posting on the message board.

03 Oct 2021, 15:26

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 03 Oct 2021, 16:40

Small correction to my previous post: the definition of symbol may still matter for the name after the dot (like "b" in the example) if there is matching case-insensitive symbol defined, but no case-sensitive one. For example:

Code:

a.B?:
dd a.b.c ; looks for a.B?.c, as it first finds a.B? namespace and then looks for c in there

Code:

a.b:
a.B?:
dd a.b.c ; looks for a.b.c, case-sensitive takes precedence

(You can see it in the error messages if you try to assemble these snippets.)

sylware wrote:

In the light of this thread, where in the manual those topics are explicited?
Because I did read a few times the manual, but it is so dense, I always manage to forget where to look and I end up posting on the message board.

It is almost exclusively discussed in chapter 2. And yes, it is very dense, because the entire main manual was written in such dense way - this is why I also added auxiliary documentation to provide more examples with in-depth discussion. Probably this topic also deserves such treatment, as another Q&A-style section there.

03 Oct 2021, 16:40

sylware

Joined: 23 Oct 2020
Posts: 462
Location: Marseille/France

sylware 03 Oct 2021, 21:15

I have to admit, I kind of dropped the case sensitive/unsensitive handling support and went full case sensitive.

I am still not decided about dropping the classic macro language to go full calm instructions. I wonder how much dropping the classic macro language (and now the case sensitive/unsensitive handling mechanics) would simplify the fasmg "specs" (implementation internals).

03 Oct 2021, 21:15

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum