[bug #36672] GRUB fails to read FAT filesystem label

[qwertial]

Follow-up Comment #4, bug #36672 (project grub):

I figured. And did just that.

Does the Debian build disable optimizations? Because some fiddling with the
compiler reveals that enabling optimizations is crucial for this to work. Um,
fail to work. It seems this off-by-one jump is deliberate. When a nested
routine is called from the containing function, the context pointer is passed
in %esi, which is pushed onto the stack in the routine and then read from
there. When doing a trampoline call, it is the trampoline which pushes the
context pointer onto the stack, so it needs to skip the push instruction in
the routine, which happens to be one byte long, and at the very beginning of
the function... Except when we are optimizing, in which case all bets are off.
I was unable to find out which particular optimization causes this, but -O1 is
enough to trigger the bug.

A workaround is to disable optimizations, preferably using
__attribute__((optimize(0))).

As for the GRUB problem, it looks like file system labels on partitions I
tested are marked with attribute value 0x28 (archive and volume label), rather
than 0x08 (just label). At least that is what iter_hook receives from its
caller. FreeDOS, dosfstools and blkid seem to have no problems with that.
Ignoring archive and read-only attributes should do it.

I think I did more than enough; and I really should not be spending any more
time on this bug. You know what needs to be done.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36672>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/